Understanding OpenShift Security Context Constraints

October 21, 2016
Alessandro Arrichiello
Related topics:
SecurityKubernetesContainersDevOps
Related products:
Red Hat OpenShift Container Platform

OpenShift gives its administrators the ability to manage a set of security context constraints (SCCs) for limiting and securing their cluster. Security context constraints allow administrators to control permissions for pods using the CLI.

SCCs allow an administrator to control the following:

  1. Running of privileged containers.
  2. Capabilities a container can request to be added.
  3. Use of host directories as volumes.
  4. The SELinux context of the container.
  5. The user ID.
  6. The use of host namespaces and networking.
  7. Allocating an 'FSGroup' that owns the pod’s volumes
  8. Configuring allowable supplemental groups
  9. Requiring the use of a read only root file system
  10. Controlling the usage of volume types
  11. Configuring allowable seccomp profiles

Note: For managing SCC you should have cluster-admin privileges.

By default six SCCs are added to the cluster, and are viewable by cluster administrators using the CLI:

  • anyuid
  • hostaccess
  • hostmount-anyuid
  • nonroot
  • privileged
  • restricted

The default Security Context is 'restricted' that secure in various different ways the final running pod. Let's take a deep look into it:

[alex@freddy ~]$ oc describe scc restricted
Name: restricted
Priority: <none>
Access:
Users: <none>
Groups: system:authenticated     [1]
Settings:
Allow Privileged: false     [2]
Default Add Capabilities: <none>
Required Drop Capabilities: SETUID,SETGID,KILL,MKNOD,SYS_CHROOT     [3]
Allowed Capabilities: <none>
Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,secret      [4]
Allow Host Network: false     [5]
Allow Host Ports: false
Allow Host PID: false
Allow Host IPC: false
Read Only Root Filesystem: false     [6]
Run As User Strategy: MustRunAsRange     [7]
UID: <none>
UID Range Min: <none>
UID Range Max: <none>
SELinux Context Strategy: MustRunAs     [8]
User: <none>
Role: <none>
Type: <none>
Level: <none>
FSGroup Strategy: MustRunAs     [9]
Ranges: <none>
Supplemental Groups Strategy: RunAsAny     [10]
Ranges: <none>

We can proceed analyzing it looking at the various numbers I placed over the previous list:

  1. Groups: this represent who's allowed using this SCC.
  2. Allow Privileged: just a boolean for enabling/disabling privileged container execution.
  3. Required Drop Capabilities: Any dropped capabilities, applied to the final running container.
  4. Allowed Volume Types: A list of the allowed volumes that the pod could actually mount. All the volume's types don't explicitally listed here will be denied.
  5. Allow Host Network: a boolean for enabling/disabling the view of the host network to the final container
  6. Read Only Root Filesystem: just a boolean for enabling or disabling read-only fs.
  7. Run As User Strategy: User IDs are constrained being set to MustRunAsRange. This forces user ID validation. (Other values: RunAsAny or MustRunAs)
  8. SELinux Context Strategy: A SELinux label is required (fot MustRunAs), which uses the project’s default label.
  9. FSGroup Strategy: fsGroup defines a pod’s "file system group" ID, which is added to the container’s supplemental groups.
  10. Supplemental Groups Strategy: The supplementalGroups ID applies to shared storage, whereas the fsGroup ID is used for block storage.

The other available SCCs let cluster admins to have a set of ready to use templates for enabling ServiceAccounts to run pods with some or full of privileges. Service accounts provide a flexible way to control API access without sharing a regular user’s credentials.

In the following paragraphs I'll describe all the necessary steps for editing existing SCCs and properly using ServiceAccounts to run existing containers.

Please note: editing SCCs may expose your hosts to security risks, please ensure to run only validated/secured containers on your OpenShift cluster.

 

Example: Running the official WordPress container

Supposing you want to run in your OpenShift platform the official WordPress container, you'll rapidly discover that the container will keep failing because of lack of privileges.

Please note: in the following example I'll use an already configured mysql server listening at address 192.168.122.1, change it according to your settings.

[alex@freddy ~]$ oc new-project wordpress
Already on project "wordpress" on server "https://192.168.123.1:8443".
[alex@freddy ~]$ oc new-app -e WORDPRESS_DB_HOST=192.168.122.1 -e WORDPRESS_DB_PASSWORD=secret docker.io/wordpress
--> Found Docker image f3cd009 (7 days old) from docker.io for "docker.io/wordpress"

* An image stream will be created as "wordpress:latest" that will track this image
* This image will be deployed in deployment config "wordpress"
* Port 80/tcp will be load balanced by service "wordpress"
* Other containers can access this service through the hostname "wordpress"
* This image declares volumes and will default to use non-persistent, host-local storage.
You can add persistent volumes later by running 'volume dc/wordpress --add ...'
* WARNING: Image "docker.io/wordpress" runs as the 'root' user which may not be permitted by your cluster administrator

--> Creating resources with label app=wordpress ...
imagestream "wordpress" created
deploymentconfig "wordpress" created
service "wordpress" created
--> Success
Run 'oc status' to view your app.
[alex@freddy ~]$ oc get pods
NAME READY STATUS RESTARTS AGE
wordpress-1-10ojk 0/1 Error 0 5s
[alex@freddy ~]$ oc logs wordpress-1-10ojk
chown: changing ownership of 'wp-config.php': Operation not permitted

Taking a look to the official container on DockerHub we can verifiy that the container expects to execute as "root" user and it expects to run a listening httpd on port 80:

[alex@freddy ~]$ docker inspect docker.io/wordpress | grep -i port -A2
"ExposedPorts": {
"80/tcp": {}
},
--
"ExposedPorts": {
"80/tcp": {}
},

The most clear and secure way to give some privileges to an OpenShift pod is via  the existing "anyuid" Security Context Constraints amd a ServiceAccount.

Let's first create a Service Account:

[alex@freddy ~]$ oc create serviceaccount wp-sa
serviceaccount "wp-sa" created

Then we can edit the "anyuid" Security Context, adding the just created ServiceAccount to the list of the allowed user to access it. We need to add to the SCC the following field:

users:
- system:serviceaccount:wordpress:wp-sa

For editing a Security Context we have to login as cluster admin and then proceed:

[alex@freddy ~]$ oc login -u system:admin
Logged into "https://192.168.123.1:8443" as "system:admin" using existing credentials.

[alex@freddy ~]$ oc edit scc anyuid
securitycontextconstraints "anyuid" edited

Ok, we're now ready for the last step, we can now edit the DeploymentConfig for using the just created ServiceAccount, adding the following field into the containers section:

spec:
  template:
   spec:
     containers:
       serviceAccount: wp-sa
       serviceAccountName: wp-sa

 

For editing the DeploymentConfig we have to login back as standard user and then proceed:

[alex@freddy ~]$ oc login
Authentication required for https://192.168.123.1:8443 (openshift)
Username: developer
Password:
Login successful.

You have one project on this server: "wordpress"

Using project "wordpress".

[alex@freddy ~]$ oc edit dc/wordpress
deploymentconfig "wordpress" edited

[alex@freddy ~]$ oc describe dc/wordpress
Name: wordpress
Namespace: wordpress
Created: 2 hours ago
Labels: app=wordpress
Annotations: openshift.io/generated-by=OpenShiftNewApp
Latest Version: 2
Selector: app=wordpress,deploymentconfig=wordpress
Replicas: 1
Triggers: Config, Image(wordpress@latest, auto=true)
Strategy: Rolling
Template:
Labels: app=wordpress
deploymentconfig=wordpress
Annotations: openshift.io/container.wordpress.image.entrypoint=["docker-entrypoint.sh","apache2-foreground"]
openshift.io/generated-by=OpenShiftNewApp
Service Account: wp-sa
...

 

Now let's check that the container is up & running thanks to the Service Account and the new Security Context:

[alex@freddy ~]$ oc get pods
NAME READY STATUS RESTARTS AGE
wordpress-2-8vxn2 1/1 Running 0 50s
[alex@freddy ~]$ oc logs wordpress-2-8vxn2
WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.4. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.4. Set the 'ServerName' directive globally to suppress this message
[Fri Oct 14 16:15:12.725438 2016] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.10 (Debian) PHP/5.6.26 configured -- resuming normal operations
[Fri Oct 14 16:15:12.725513 2016] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

That's all!

Interested on improving the DeploymentConfig? Do you want to deploy a mysql server pod?

Take a look to a ready-to-use template that I wrote: http://wordpress.inmyopenshift.cloud

 

Feel free to leave comments with any question you may have!