-
Notifications
You must be signed in to change notification settings - Fork 23
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
Set SCC's RunAsUser
as MustRunAsRange
#254
Conversation
My test was very basic local run. Just deployed a fresh OpenShift cluster (v4.15.0) in AWS, and then essentially kubectl apply -f resources/scc.yaml
make install
make run
# for some reason had to manually create the ClusterRole
# should I be worried about this? but not seeing how my change can be related.
kubectl apply -f bundle/manifests/nginx-ingress-operator-nginx-ingress-admin_rbac.authorization.k8s.io_v1_clusterrole.yaml
kubectl apply -f config/samples/charts_v1alpha1_nginxingress.yaml The Controller was spun up with Let me know what further experiments could be preferable. |
RunAsUser
as MustRunAsRange
RunAsUser
as MustRunAsRange
151224f
to
5f4c1c6
Compare
4b7ead3
to
66fe779
Compare
Hey @sigv, only scc yamls are exclusive to this operator repo, rest of the files are synced from https://github.com/nginxinc/kubernetes-ingress/tree/main/charts/nginx-ingress, so any change needed will have to go there initially |
Understandable - this change is blocked on nginx/kubernetes-ingress#3665. The chart must be updated for SCC to be updated. Without this, startup would fail as SCC requires dynamic range, but chart enforces specific UID. |
thanks @sigv, left a comment there in NIC pr |
@sigv you can remove the changes from helm directory as well, keep the scc ones as they're specific to operator |
Reverted |
Upstream Helm Chart is removing explicit `runAsUser` value from the Deployment and DaemonSet resources. This practically means the UID will be inherited from image's Dockerfile. Users on vanilla Kubernetes clusters will not observe a change in behavior, unless they have exotic configurations. However, OpenShift does have additional security measures. It suggests using randomized UIDs/GIDs for workloads. To enable this, the custom Security Context Constraint resources are being updated. The `MustRunAsRange` policy is utilized with pre-allocated values (no explicit range min/max), which effectively allows OpenShift to pick its own ranges.
Hey @sigv can you check min max values are required as per https://docs.openshift.com/container-platform/4.15/authentication/managing-security-context-constraints.html#authorization-SCC-strategies_configuring-internal-oauth |
This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR was closed because it has been stalled for 10 days with no activity. |
Proposed changes
Upstream Helm Chart is removing explicit
runAsUser
value from the Deployment and DaemonSet resources. This practically means the UID will be inherited from image's Dockerfile.Users on vanilla Kubernetes clusters will not observe a change in behavior, unless they have exotic configurations.
However, OpenShift does have additional security measures. It suggests using randomized UIDs/GIDs for workloads. To enable this, the custom Security Context Constraint resources are being updated. The
MustRunAsRange
policy is utilized with pre-allocated values (no explicit range min/max), which effectively allows OpenShift to pick its own ranges.Relates to nginx/kubernetes-ingress#5422.
Checklist
Before creating a PR, run through this checklist and mark each as complete.