-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support OpenShift's built-in restricted-v2
Security Context Constraint
#5422
Comments
Hi @sigv thanks for reporting! Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂 Cheers! |
@sigv we made an update to our Helm template & values to properties of In this case your deployment in Openshift can remove |
Is your feature request related to a problem? Please describe.
Security teams prefer referencing default (built-in) security restrictions. In OpenShift (v4.11+) the
restricted-v2
Security Context Constraint is default, and previously (up to v4.10) therestricted
SCC was default. Both of these SCCs require that a pod is run as a user in a pre-allocated range of UIDs. This conflicts current Nginx Ingress Controller set-up which uses UID 101.Describe the solution you'd like
Nginx Ingress Controller should stop specifying explicit UID in securityContext. Deployments in vanilla Kubernetes will inherit container image default UID, retaining existing behavior. Deployments in OpenShift will be allowed to choose any UID. Users with OpenShift, with existing SCC for NIC would also retain existing RunAsUser behavior.
Describe alternatives you've considered
This is an explicit security requirement. Only alternative is WONTFIX - to not comply with OpenShift requirements.
Additional context
The text was updated successfully, but these errors were encountered: