I was wondering what is the best way to define user role to assign to Security Context in Pod and Container?
It is not advised to grant user as root and as I know that if the user has too powerful role then when it writes file to node volume and next time when we deploy new container, it is likely that we do not have sufficient permission to delete file written in container by powerful user.
In particular, in google Kubernetes I want to avoid the scenario below like when I deploy app in docker environment: When A is deploying app by running docker: docker run ... if process inside container is run by user B who is more powerful than A then it is likely that A cannot delete file written by B. Not sure if this case can happen in google K8S
After a while, I think the mentioned scenario does not happen in K8S. K8S would manage the container resources when redeploying, updating pod by its internal mechanism
You might mix Linux Capabilities with Security Context in Pod and Container in order to provide finer grained breakdown of the privileges traditionally associated with the superuser (root or uid=0). Some of these capabilities can be used to escalate privileges or for container breakout, and may be restricted by the PodSecurityPolicy. For more details on Linux capabilities, see capabilities.
Said that, the PodSecurityPolicy will allow you to control security sensitive aspects of the pod specification such as: Allocating an FSGroup that owns the pod's volumes, the user and group IDs of the container and additionally the Linux Capabilities to provide finer privileges.
For Users and Groups, due to RunAsUser (MustRunAs) and RunAsGroup (MustRunAs) requires at lest of one range to be specified then you should have sufficient permission to delete file written in container by any range defined in RunAsUser or RunAsGroup. I would recommend you to use MustRunAsNonRoot for Users and Groups to avoid the scenario described.
As best practice, if you have more than one application running on Kubernetes cluster, then each application should run into its own namespace to avoid name collisions and for each application a different uid and MCS label should be used. Additionally, is suggested that all containers run as a single non-root user. Use cases described here provides some of these considerations when Security Contexts for Nodes and Containers are used.
In this link you can find more details about Pod Security Policy
In that case, if security context for the pods is not set to "privileged" then containers will not get root privileges. If you are a cluster administrator, you can use a Pod Security Policy to restrict the use of privileged containers.
In this document you will find the 7 Best Practices Operating Containers, these practices also would apply for Dockers. Basically you must avoid privileged containers to avoid the scenario described.