You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All use of the USER instruction to setup the final closing user for an image should use:
USER $CNB_USER_ID
and not:
USER cnb
The reason for this is that it ensures that the user in the image manifest is recorded as an integer user ID that can then be used by a container platform such as Kubernetes, to verify that the image will not run as the root user.
This comes up when using pod security policies in Kubernetes. By using a name for USER, the platform cannot verify what actual user ID the image would run as. This means you can't use MustRunAs for the runUser setting of a pod security policy as it will be rejected. Instead you are forced to use in the pod security policy RunAsAny which means you have a service account in the namespace which a user could then apply to run any image as root. So using a user name for USER is going to force people to configure their platform in a less secure way when using pod security policies.
The reason Kubernetes will reject the image where USER is a user name rather than an integer user ID, is that a user name which is not root is not a guarantee that it will not run as user ID 0, as the non root user name could map to user ID 0 in the /etc/passwd file, which the platform wouldn't be able to validate.
Any examples and documentation should therefore use an integer user ID for USER. In this case it can be picked up from the environment variable set from the original build argument.
The text was updated successfully, but these errors were encountered:
All use of the
USER
instruction to setup the final closing user for an image should use:and not:
The reason for this is that it ensures that the user in the image manifest is recorded as an integer user ID that can then be used by a container platform such as Kubernetes, to verify that the image will not run as the
root
user.This comes up when using pod security policies in Kubernetes. By using a name for
USER
, the platform cannot verify what actual user ID the image would run as. This means you can't useMustRunAs
for therunUser
setting of a pod security policy as it will be rejected. Instead you are forced to use in the pod security policyRunAsAny
which means you have a service account in the namespace which a user could then apply to run any image asroot
. So using a user name forUSER
is going to force people to configure their platform in a less secure way when using pod security policies.The reason Kubernetes will reject the image where
USER
is a user name rather than an integer user ID, is that a user name which is notroot
is not a guarantee that it will not run as user ID 0, as the nonroot
user name could map to user ID 0 in the/etc/passwd
file, which the platform wouldn't be able to validate.Any examples and documentation should therefore use an integer user ID for
USER
. In this case it can be picked up from the environment variable set from the original build argument.The text was updated successfully, but these errors were encountered: