Using runAsNonRoot in Kubernetes


Using runAsNonRoot in Kubernetes
We’ve been planning for a long time to introduce securityContext: runAsNonRoot: true
as a requirement to our pod configurations for a while now.
securityContext: runAsNonRoot: true
Testing this today I’ve learnt that since v1.8.4
(I think) you also have to specify a particular UID for the user running the container, e.g runAsUser: 333
.
v1.8.4
runAsUser: 333
This means we not only have to tell developers to ensure their containers don’t run as root, but also specify a specific UID that they should run as, which makes this significantly more problematic for us to introduce.
Have I understood this correctly? What are others doing in this area? To leverage runAsNonRoot
is it now required that Docker containers run with a specific and known UID?
runAsNonRoot
2 Answers
2
The Kubernetes Pod SecurityContext provides two options runAsNonRoot
and runAsUser
to enforce non root users. You can use both options separate from each other because they test for different configurations.
runAsNonRoot
runAsUser
When you set runAsNonRoot: true
you require that the container will run with a user with UID 0. No matter which UID your user has.
When you set runAsUser: 333
you require that the container will run with a user with UID 333.
runAsNonRoot: true
runAsUser: 333
What are others doing in this area?
We are using runAsUser
in situations where we don't want root to be used. Granted, those situations are not that frequent as you might think, since philosophy of deployment of 'processes' as separated pod's containers inside kubernetes cluster architecture differs from traditional compound monolithic deployment on single host where security implications of breach are quite different...
runAsUser
Most of our local development is done either on minicube or docker edge with k8s manifests so setup is as close as possible to our deployment cluster (apart from obvious limits). With that said, we don't have issues with user id allocation since initialization of persistent volume is not done externally so all file user/group ownership is done within pods with proper file permissions. On very rare occasions that docker is used for development, developer is instructed to set appropriate permissions manually across mounted volumes but that rare happens.
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.