This post was originally posted to link

In this post, I’m highlighting some key concepts which are related to Security Context Constraint (SCC) and how you can secure your Pod’s containers by following my lessons learned.

Let’s get started.

The Concepts

The OpenShift Container Platform provides Security Context Constraint (SCC) feature that controls the actions that a Pod performs and which capabilities the Pod can access.

In simple terms, when you execute a container, part of the Pod, you allow or deny security capabilities that the container is able to use. For this reason, the Pod runs with least-privilege without unnecessary cgroup or SELinux capabilities. On OpenShift, SCCs play a critical role.

The OpenShift Container Application Platform provides a set of predefined Security Context Constraints that can be used, modified, or extended by any administrator. By default, the execution of any container will be granted the restricted SCC and only the capabilities defined by that SCC.

Lessons Learned

1. You can use a pre-defined SCC

Each predefined SCC has a set of allowed and dropped capabilities. To check predefined SCCs run:

$ oc get scc

2. There are default security context constraints strategies

For defining rules for custom SCC, you must need to provide some strategies depending on your application requirement. These strategies must be unique from other SCCs and should be more restrictive so that the pod will pick it up at the time of creation.
There are predefined strategies like MustRunAs, MustRunAsRange, MustRunAsNonRoot, RunAsAny which you can use to specify SCC policies.

3. You should check your Project’s SCC settings

In order to customize your SCC, you should know the pre-allocated range of capabilities per Project.

To check the default allocated range of capabilities per project, run below command:

$ oc describe project <project-name> | grep scc

4. You should create a new SCC rather than updating the default available. Do not edit the generally available SCC.

You can create a custom SSC using the OpenShift CLI.

Prerequisites:

• Install the OpenShift CLI (oc).
• Log in to the cluster as a user with the cluster-admin role.

Use the predefined SCC template for creating new SCC and update the rules for UID, GID checking as per the requirement to make your application more restrictive if needed.

To make use of custom SCC you need to add it to service account. For this you can either create a service account or add the custom SCC to Default service account.

If you want to enable SCC, follow these steps:

1. Create Service Account

$ oc create sa my-custom-sa
serviceaccount/my-custom-sa created

$ oc get sa
NAME           SECRETS   AGE
builder        1         27m
default        1         27m
deployer       1         27m
my-custom-sa   1         3m1s

2. Copy the template of restricted SCC to new file

$ oc get scc restricted-v2 -oyaml > custom-scc.yaml

3. Add changes as per your requirement

$ vi custom-scc.yaml

Note: You must change the name of SCC first, otherwise it will modify the predefined SCC which is not recommended.

4. Create the custom SCC

$ oc create -f custom-scc.yaml
securitycontextconstraints.security.openshift.io/my-custom-scc created

5. Add the custom SCC to newly created service account and add your custom SCC to service account my-custom-sa and all authenticated users can access this SCC because of adding it to system:authenticated

a. Verify the project is the one you intend

$ oc project
Using project "demo"

b. Add the SSC to the service account

$ oc adm policy add-scc-to-user custom-scc -z my-custom-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:custom-scc added: "my-custom-sa"

c. Add SCC to the system:authenticated role

$ oc adm policy add-scc-to-group custom-scc system:authenticated
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:custom-scc added: "system:authenticated"

6. Verify the rules of custom SCC

# oc describe scc my-custom-scc
Name:                                           my-custom-scc
Priority:                                       1
Access:
  Users:                                        system:serviceaccount:openshift-compliance:my-custom-sa
  Groups:                                       <none>
Settings:
  Allow Privileged:                             false
  Allow Privilege Escalation:                   false
  Default Add Capabilities:                     <none>
  Required Drop Capabilities:                   KILL,MKNOD
  Allowed Capabilities:                         NET_BIND_SERVICE
  Allowed Seccomp Profiles:                     runtime/default
  Allowed Volume Types:                         configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  Allowed Flexvolumes:                          <all>
  Allowed Unsafe Sysctls:                       <none>
  Forbidden Sysctls:                            <none>
  Allow Host Network:                           false
  Allow Host Ports:                             false
  Allow Host PID:                               false
  Allow Host IPC:                               false
  Read Only Root Filesystem:                    false
  Run As User Strategy: MustRunAsRange
    UID:                                        <none>
    UID Range Min:                              3000
    UID Range Max:                              5000
  SELinux Context Strategy: MustRunAs
    User:                                       <none>
    Role:                                       <none>
    Type:                                       <none>
    Level:                                      <none>
  FSGroup Strategy: MustRunAs
    Ranges:                                     <none>
  Supplemental Groups Strategy: MustRunAs
    Ranges:                                     2000-6000

7. Create a Pod that matches the rules of custom SCC

a. Create the Pod definition

$ cat test-pod-scc2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-context-constraint-1
spec:
  securityContext:
    runAsUser: 3333
    runAsGroup: 65534
    supplementalGroups: [5555]
    runAsNonRoot: true
  seccompProfile:
      type: RuntimeDefault
  containers:
  - name: sec-ctx-demo-1
    image: docker.io/library/tomcat:9.0
    volumeMounts:
    - name: mypv
      mountPath: "/tmp"
    securityContext:
      runAsUser: 3333
      supplementalGroups: [5555]
      seccompProfile:
        type: RuntimeDefault
      capabilities:
        drop: ["ALL"]
      allowPrivilegeEscalation: false
  serviceAccountName: my-custom-sa
  volumes:
  - name: mypv
    persistentVolumeClaim:
      claimName: nfs-claim1

b. Create the Pod

$ oc create -f test-pod-scc2.yaml
pod/security-context-constraint-1 created

8. Check if the custom SCC has been assigned to pod:

$ oc get pod security-context-constraint-1 -oyaml | grep scc
openshift.io/scc: my-custom-scc

5. The SCC has a matching and priority.

All SCCs are active at the same time - and will be selected depending on which SCC is matched by the requested pod. You can learn more at SCC Prioritization.

You apply multiple SCCs to a Service Account. The default SCC is always restricted. The matching goes by priority first, then most restrictive policy, then by name. And if a policy does not match a specific request, another one might "jump in" and "help out".

Thus, in this blogpost you learned some basics about SCC, strategies to define custom SCC, creating custom SCC and lessons learned with SCC.

Thanks for reading! I hope you found this helpful:)