[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: runAsUser.Type values

Great. Thanks for the info. Seems to make sense.

For completeness, yes, the container of concern runs as a specific non-root user (e.g. specified in the Dockerfile with a USER statement), but cannot run as a randomly assigned userid. I imagine this is quite a common scenario.


On 09/06/2017 16:05, Vyacheslav Semushin wrote:
2017-06-09 12:26 GMT+02:00 Tim Dudgeon <tdudgeon ml gmail com>:

OK, thanks.

What's the recommended approach to running a specific container that cannot work with an allocated ID from the range.

In this case I'd recommend to:
1) explicitly state the fact that this container requires a specific ID by setting Pod.Spec.SecurityContext.RunAsUser field
2) create an SCC with RunAsUser.MustRunAs (or RunAsUser.MustRunAsRange with the same uidRangeMin and uidRangeMax)
3) depending on who is creating a pod [*], grant him permission to this SCC
4) if pod is being created by ServiceAccount (SA) you can also set Pod.Spec.ServiceAccountName field to the name of this SA

[*] This is important! Without knowing this info, you could grant permissions to the wrong user/SA and nothing will work.

I try running such an image (oc new-app repo/image) as a normal user and it fails as it doesn't run with a randomly assigned userid.

Do you mean that this image needs to be run as UID like 1000 and not as 10005000?

I can resolve this by editing the "restricted" SCC configuration, but that would apply to all containers which might not be what is wanted.
Instead I tried doing this with the system:admin user as I believed that would do this with the privileged SCC, but that does not seem to be the case as the container fails to start for the same reason as when running with a normal user.

I can guess that this pod was admitted by "anyuid" SCC because it didn't request any privileged features (it even didn't request UID). You can determine which SCC was used for a pod by execuring the following:

$ oc describe pod examine-caps-3xxjw | grep Policy
Security Policy:    restricted

Also it didn't have a USER directive in its Dockerfile and probably was run under root user.

Unfortunately, I don't have enough information to say something sure. Only you know which image you're running and how its Docker looks like.

So what is the recommended approach for running a specific container with a different SCC?

See above.

Slava Semushin | OpenShift

users mailing list
users lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]