Clayton Am referring OS user name running a specific process not UID or user id. While inspecting pod definitions, I can see the flexibility of specifying UID, however am not seeing similar mechanism to run container or processes ( in container) using a pre defined OS user name or group.
Just sake of example, say, I want to run apache process or tomcat process from container run using www:www or tomcat:tomcat user and group combination. Is it possible? -- Srinivas Kotaru From: "ccole...@redhat.com<mailto:ccole...@redhat.com>" <ccole...@redhat.com<mailto:ccole...@redhat.com>> Date: Tuesday, January 19, 2016 at 10:44 AM To: skotaru <skot...@cisco.com<mailto:skot...@cisco.com>> Cc: Paul Weil <pw...@redhat.com<mailto:pw...@redhat.com>>, dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> Subject: Re: Clarification on container security in OpenShift 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) <skot...@cisco.com<mailto:skot...@cisco.com>> 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: <dev-boun...@lists.openshift.redhat.com<mailto:dev-boun...@lists.openshift.redhat.com>> on behalf of "ccole...@redhat.com<mailto:ccole...@redhat.com>" <ccole...@redhat.com<mailto:ccole...@redhat.com>> Date: Tuesday, January 19, 2016 at 9:57 AM To: Paul Weil <pw...@redhat.com<mailto:pw...@redhat.com>> Cc: dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> 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 <pw...@redhat.com<mailto:pw...@redhat.com>> 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 <rishi.investig...@gmail.com<mailto:rishi.investig...@gmail.com>> 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<http://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<http://openshift.io/deployment-config.latest-version>: "1" openshift.io/deployment-config.name<http://openshift.io/deployment-config.name>: nodejs-sample-app openshift.io/deployment.name<http://openshift.io/deployment.name>: nodejs-sample-app-1 openshift.io/generated-by<http://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<http://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 <pw...@redhat.com<mailto:pw...@redhat.com>> 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 <rishi.investig...@gmail.com<mailto:rishi.investig...@gmail.com>> 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 dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev