Not sure if this is exactly what you are asking, but Openshift allows you to partition the local UNIX user ID space across the entire cluster automatically. Every project gets a 10k block by default. Those are not shared, so that block uniquely identifies any process in that project on any node. The default policy forces pods to run in uids in that block - again, that cannot be escaped by end users by default.
If you want to identify all pods via the API, that is what labels and annotations are for. Enforcing a unique label on each pod in a namespace should be possible, although that's only visible via the API. On Jan 19, 2016, at 1:31 PM, Srinivas Naga Kotaru (skotaru) < [email protected]> wrote: Clayton and Team Is it possible to run all containers from a specific application to use a dedicated OS user name ( UUID in OSE 2.X). Am not referring UID which is typically a numeric number and control local access. We have a requirement for database access control perceptive where every application ( all instances of that app) should use a dedicated OS user name ( UUID) and it should be predicable well in advance ( unlike OSE 2.X auto scaling where UUID prediction is difficult). -- *Srinivas Kotaru* From: <[email protected]> on behalf of " [email protected]" <[email protected]> Date: Tuesday, January 19, 2016 at 9:57 AM To: Paul Weil <[email protected]> Cc: dev <[email protected]> Subject: Re: Clarification on container security in OpenShift If you had specified uid 0 in your pod definition, you would receive an error (instead of being defaulted). We do this defaulting by default to protect from the classic "it's usually a bad idea to run arbitrary software from the Internet as root on your machines" - the step Paul mentions is the equivalent of requiring you to answer "are you sure you want to allow this to run as root?" On Jan 19, 2016, at 12:51 PM, Paul Weil <[email protected]> wrote: You are correct, the container will not run as root with pod spec that is shown. The pod spec indicates that you validated under the restricted SCC and were given the UID 1000030000. When your container is launched it will be configured to run as 1000030000 regardless of what is in the docker file. If you would like the container to run as root you can grant access to the anyuid SCC for the service account that the pod is using. https://docs.openshift.org/latest/admin_guide/manage_scc.html#add-an-scc-to-a-user-or-group. On Tue, Jan 19, 2016 at 11:43 AM, Rishi Misra <[email protected]> wrote: > Thanks for your response. Perhaps interpreting this will help me > understand SCC better - My app pod looks like: > > /======================================/ > oc get pod nodejs-sample-app-1-fpiha -o yaml > apiVersion: v1 > kind: Pod > metadata: > annotations: > kubernetes.io/created-by: | > > {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"test","name":"nodejs-sample-app-1","uid":"6fd8f412-bb9a-11e5-9f87-02000000002e","apiVersion":"v1","resourceVersion":"328"}} > openshift.io/deployment-config.latest-version: "1" > openshift.io/deployment-config.name: nodejs-sample-app > openshift.io/deployment.name: nodejs-sample-app-1 > openshift.io/generated-by: OpenShiftNewApp > *openshift.io/scc <http://openshift.io/scc>: restricted* > creationTimestamp: 2016-01-15T15:12:54Z > generateName: nodejs-sample-app-1- > labels: > app: nodejs-sample-app > deployment: nodejs-sample-app-1 > deploymentconfig: nodejs-sample-app > name: nodejs-sample-app-1-fpiha > namespace: test > resourceVersion: "1729" > selfLink: /api/v1/namespaces/test/pods/nodejs-sample-app-1-fpiha > *uid: 737d0f9a-bb9a-11e5-9f87-02000000002e* > spec: > containers: > - image: openshift/nodejs-sample-app:forOpenShift > imagePullPolicy: IfNotPresent > name: nodejs-sample-app > ports: > - containerPort: 8080 > protocol: TCP > resources: {} > * securityContext:* > * privileged: false* > * runAsUser: 1000030000* > * seLinuxOptions:* > * level: s0:c6,c0* > terminationMessagePath: /dev/termination-log > volumeMounts: > - mountPath: /var/run/secrets/kubernetes.io/serviceaccount > name: default-token-8dwhf > readOnly: true > dnsPolicy: ClusterFirst > host: xxx.xxxx.xxxx > imagePullSecrets: > - name: default-dockercfg-i1ke5 > nodeName: xxx.xxxx.xxxx > restartPolicy: Always > securityContext: > seLinuxOptions: > level: s0:c6,c0 > serviceAccount: default > serviceAccountName: default > terminationGracePeriodSeconds: 30 > volumes: > - name: default-token-8dwhf > secret: > secretName: default-token-8dwhf > status: > conditions: > - lastProbeTime: null > lastTransitionTime: 2016-01-19T16:10:00Z > status: "True" > type: Ready > containerStatuses: > - containerID: > docker://ca9a288d9ee1fe48517e18e5f6f6b1def28e0ba605962545063f42fbf1f38f38 > image: openshift/nodejs-sample-app:forOpenShift > imageID: > docker://a7782aa25f2463169c43423490297c3a5cf9237b34e7cc772ac2f3ab06b5d302 > lastState: {} > name: nodejs-sample-app > ready: true > restartCount: 0 > state: > running: > startedAt: 2016-01-15T15:12:57Z > hostIP: x.xx.xx.xxx > phase: Running > podIP: 172.17.0.2 > startTime: 2016-01-19T16:10:00Z > /======================================/ > > Is this telling me that my container is running as non-root user ( > *1000030000*) and security context is *restricted*? How do I interpret > this container from security context? > > I had specifically commented out USER section in my Dockerfile when > creating this image as it was creating problems when copying things to > root. This led me to think that this image will be run as "root" user in > OpenShift which does not appear to be the case by looking at pod details: > > # Drop the root user and make the content of /opt/app-root owned by user > 1001 > #RUN chown -R 1001:0 /opt/app-root > #USER 1001 > > > On Tue, Jan 19, 2016 at 11:03 AM, Paul Weil <[email protected]> wrote: > >> The effective UID the container uses depends on who is launching the >> container and what SecurityContextConstraints (SCC) they have access to. >> >> Generally, a non-privileged user on a cluster using the default >> SecurityContextConstraints will have a UID set on their pod that is a >> non-root UID. If you created a pod as an admin user or with a service >> account that has access to SCCs that allow running as root you can run run >> the container as root. >> >> You can view which SCC the pod validated against by looking at the >> annotations on the pod (oc get pod <name> -o json|yaml) >> >> Info on how SCCs are sorted if you have access to multiple: >> https://docs.openshift.org/latest/architecture/additional_concepts/authorization.html#scc-prioritization >> >> On Tue, Jan 19, 2016 at 10:49 AM, Rishi Misra < >> [email protected]> wrote: >> >>> Hello - as per: >>> https://hub.docker.com/r/openshift/origin-custom-docker-builder/: >>> "Containers run as a non-root unique user that is separate from other >>> system users" >>> >>> In my experience I was able to run my Docker app image as a root user in >>> OpenShift without modifying any security context. Perhaps there is >>> something about the statement above that I do not understand very well. >>> Could someone please clarify if all Docker images running in OpenShift need >>> to be non-root?. >>> >>> Thanks. >>> >>> _______________________________________________ >>> dev mailing list >>> [email protected] >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >>> >> > _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
