Understanding OpenShift Security Context Constraints

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’ in several different ways, thus securing the final running pod. Let’s take a deeper 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 to analyze it by looking at the various numbers I placed over the previous list:

1. Groups: this represents who’s allowed to use 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 that are not explicitly 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 and set to MustRunAsRange. This forces user ID validation (other values: RunAsAny or MustRunAs).
8. SELinux Context Strategy: An SELinux label is required (for 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 have a set of ready-to-use templates for enabling ServiceAccounts to run pods with partial or full 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 the official WordPress container in your OpenShift platform. 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 at the official container on DockerHub, we can verify 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 clearest and most secure way to give some privileges to an OpenShift pod is via the existing “anyuid” Security Context Constraints and 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 users allowed 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 log in as a 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, now we’re ready for the last step. We can now edit the DeploymentConfig for using the newly 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 log back in as a 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 and 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 in improving the DeploymentConfig? Do you want to deploy a MySQL server pod?

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

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