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
`build/Dockerfile` specifies `USER 101` for `common` target,
which is re-applied into the final images. Helm Chart/Manifests
do not need to specify UID explicitly, and can instead use
the image's UID. (PodSecurityContext v1 core specifies `runAsUser`
defaults to user specified in image metadata if unspecified.)
The existing `runAsNonRoot: true` flag (already in place) will ensure
during runtime that the image is configured with a custom user ID.
This is notably helpful for users running OpenShift, because OpenShift
attempts to enforce custom UID/GID ranges for individual namespaces
as part of `restricted-v2` Security Context Constraint. When removing
hard-coded values from manifests, OpenShift will be able to assign its
own UID/GID.
In practice, this means a different model of configuring file system
permissions. OpenShift assigns the container process GID 0 as
supplemental to assist with that. Locations that are expected to be
written to must be owned by GID 0, with group write permissions.
Previous changes to `main` have ensured that is the case.
Init container copying files is not a concern, as we will
have the same UID as owner there as the main NIC container.
Reference: https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids
0 commit comments