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.
Tim
On 09/06/2017 16:05, Vyacheslav Semushin wrote:
2017-06-09 12:26 GMT+02:00 Tim Dudgeon <tdudgeon...@gmail.com
<mailto:tdudgeon...@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
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
