How to setting up Security Context Constraints ( SCC )

What is SCC ?

A security context Constraints?defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to. Similar to the way that RBAC resources control user access, administrators can use?security context constraints?(SCCs) to control permissions. These permissions include actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system

Why to implemente it

Product security were recently notified of a vulnerability in the form of a container privilege escalation . The vulnerability details that when a Dockerfile alters the permissions of it's own /etc/passwd file, it allows for any user (within that container) to escalate to root.

Openshift and likewise ( Kubernetes ) does not currently support user namespaces. This means that if a process is run as root from within a container, they have the equivalent permissions of root on the host.

By default Openshift runs containers in restricted SCC profile. Specificaly this means that SETUID and SETGID are two systemcalls which are blocked in the container. Furthermore, due to Openshift employing a multilayered approach to security( cgroups, SeLinux, seccomp ...) it also restricts any attempts to access other containers or host resources .

Nevertheless, it's still not desirable as it unnecessarily increase the attack surface !

Goal:

This hands-on tutorial is for everyone who are interested in learning how to deploy workloads on OpenShift cluster that need access to protected Linux Functions. I going to show you how to specify secure contexts ( SCs ) in the deployment manifest to configure the container with the access the application needs. It also teaches how to configure security context constraints to grant that access to the deployment.

The security context (SC) must explicitly request access to perform functions such as :

• Run the process as a specific user or group
• Make the process a member of additional groups
• Run a privileged container
• Execute protected commands such as the KILL command

The deployment will request this access but an SCC must approve it.

Things to know before we start :

• Never apply SCC or SCS on default or kube-system namespaces !

1. Setup SCC

By default the restricted SCC will be used. It denies access to all host features and requires pods to be run with UID, and SeLinux context that are allocated to the namespace. This is the most restrictive SCC and it is used by default for authenticated users.

We are going to specifying SCC / SCS to request the permissions required by the pod and the container. On our deployment.yaml file we select the service account that is used to validate the requested permissions.

By default when Openshift starts a container, it uses an arbitrarily assigned user ID and add the root groupID . we will specify a new id user, group and fsgroup.

Screenshot of deployment.yaml

• 1 - SecurityContext?for the container was given by?runAsUser: 100600000 and?runAsGroup: 100600000.

• 2 - SecurityContext?for the pod is given?by seLinuxOptions?and an?fsGroup?setting.

• ?3 ServiceAccountName?is? myServiceAccountName. You will change this later.

Create / edit your SCC

• 1 . Change allowPrivilegeEscalation to false so it will not allow for any user (within that container) to escalate to root.
• 2 . Set the fsgroup max and min
• 3. If minimum and maximum values are not defined it will use pre-allocated values.
• 4. You assigned a?security context constraint (SCC)?to the service account that grants the requested access. The SCC can be assigned directly to the service account or indirectly via an RBAC role or group.

Create the service account who will be use

oc create serviceaccount myServiceAccountName --namespace NAMESPACE_NAME        

?An OpenShift service account is a special type of user account that is used programmatically without using a regular user’s credentials.

Create the role & roleBinding

We create a role that uses the SCC. How to create a role in kubernetes

We are binding the role to our service account on step 2 . Dont forget to add your role name in step 1

As part of creating the role and role binding, you associated the SCC with the role and bound it to the service account. This associates the service account with the SCC such that any pod running as the service account has access to the SCC.

Run your deployment

Now that you’ve customized the SCs and created a custom SCC to validate it, let have a look at the results.

Get the full YAML description of the pod to see the details. The interesting part is the annotation that shows what SCC was used, the container?securityContext, and the pod?securityContext.

1 - If you can see your scc name on the pod.yaml file you are on thr ight way

2 - The security context for the container was given?runAsUser: 1000610005?and?runAsGroup: 1000620004.

3 - The security context for the pod.

4 - The service account you just created and assigned your one SCC

How to test your container’s runtime permissions !

Mount volume on your ?containers and use a terminal to see the results.

kubectl exec -it scc-demo -- /bin/bash
#
oc rsh  scc-demo        

What do we see ? :

• We are using the user ID (uid) or group ID (gid) from our deployment manifest.
• The supplemental groups that we requested have also been created, and our user is a member of those groups.
• The user is also a member of the file system group. This ID is specified in the pod?securityContext.fsGroup.

Let see what happens when we try to write a file.

Let's do a series of tests to see if we can write in different places? .

     Command                              Description          
 
echo hello > /var/test/testSCC.txt        Write  a file on the volume   
       
echo hello > /tmp/hello.txt               Write  a file in the temp directory  

echo hello > /fail.txt                   Try to write a file in the root directory 
 
ls -l /tmp/hello.txt /var/test/testSCC.txt Check the permissions on your files
        

• In?/tmp directory, the file we created is owned by our specified?1000610005/1000620004?(uid/gid?instead of a project default like?1000620000/root).
• On the volume, the file we created is owned by?1000610005/1000603000 (our specified?uid/fsGroup?instead of a project default like?1000620000/1000620000).
• If the volume was shared storage, containers with different user IDs?would?be able to share data with members of the same group.

When a file system is backed by storage that supports fsGroup, the directory permissions are set so that files created in this directory are owned by the group. This allows file sharing for containers that run as different users in the same group (for example, 2 containers in 1 pod or multiple pod instances using persistent volumes). For other directories or other types of storage, the supplemental groups can be used similarly by setting the desired supplemental group as a directory or file owner.

Errors that you may encounter

ERROR-1 If the pod failed to be created .

ods "xxxx-xxx-5bcdb4d67c-" is forbidden: unable to validate against any security context constraint: [provider "xxx-xxx": forbidden: not usable by user or serviceaccount, provider "anyuid": forbidden: not usable by user or serviceaccount, provider restricted: .spec.securityContext.fsGroup: Invalid value: []int64{1000603000}: 1000603000 is not allowed group, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "custom-scc": forbidden: not usable by user or serviceaccount......        

You probably forgot to add the user on the scc check Create / edit your SCC

ERROR-2 if the pod has been created but the pod.yaml file don't have the right custom-scc

You made a mistake on service account check :

• Create the role & roleBinding
• Screenshot of deployment.yaml ( 3 )

Useful command :

List all pods with the scc and service account associated

oc get pods -o "custom-columns=POD NAME:.metadata.name,SCC:.metadata.annotations.openshift\.io/scc,SERVICEACCOUNT:.spec.serviceAccountName"
        

INDEX:

Red Hat Universal Base Image 8 Minimal

MANAGING SECURITY CONTEXT CONSTRAINTS

SCC & Seccomp