Red Hat OpenShift Container Platform

Verifying the default seccomp profile applied to a pod

Red Hat OpenShift Container Platform ships with a default seccomp profile that is referenced as runtime/default. In {product-version}, newly created pods have the Security Context Constraint (SCC) set to restricted-v2 and the default seccomp profile applies to the pod.

Procedure

You can verify the Security Context Constraint (SCC) and the default seccomp profile set on a pod by running the following commands:

Verify what pods are running in the namespace:

$ oc get pods -n <namespace>

For example, to verify what pods are running in the workshop namespace run the following:

$ oc get pods -n workshop

Example output

NAME                READY   STATUS      RESTARTS   AGE
parksmap-1-4xkwf    1/1     Running     0          2m17s
parksmap-1-deploy   0/1     Completed   0          2m22s

Inspect the pods:

$ oc get pod parksmap-1-4xkwf -n workshop -o yaml

Example output

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "ovn-kubernetes",
          "interface": "eth0",
          "ips": [
              "10.131.0.18"
          ],
          "default": true,
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "ovn-kubernetes",
          "interface": "eth0",
          "ips": [
              "10.131.0.18"
          ],
          "default": true,
          "dns": {}
      }]
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: parksmap
    openshift.io/deployment.name: parksmap-1
    openshift.io/generated-by: OpenShiftWebConsole
    openshift.io/scc: restricted-v2 
    seccomp.security.alpha.kubernetes.io/pod: runtime/default

	The `restricted-v2` SCC is added by default if your workload does not have access to a different SCC.
	Newly created pods in {product-version} will have the seccomp profile configured to `runtime/default` as mandated by the SCC.

Upgraded cluster

In clusters upgraded to {product-version} all authenticated users have access to the restricted and restricted-v2 SCC.

A workload admitted by the SCC restricted for example, on a Red Hat OpenShift Container Platform v4.10 cluster when upgraded may get admitted by restricted-v2. This is because restricted-v2 is the more restrictive SCC between restricted and restricted-v2.

The workload must be able to run with retricted-v2.

Conversely with a workload that requires privilegeEscalation: true this workload will continue to have the restricted SCC available for any authenticated user. This is because restricted-v2 does not allow privilegeEscalation.

Newly installed cluster

For newly installed Red Hat OpenShift Container Platform 4.11 or later clusters, the restricted-v2 replaces the restricted SCC as an SCC that is available to be used by any authenticated user. A workload with privilegeEscalation: true, is not admitted into the cluster since restricted-v2 is the only SCC available for authenticated users by default.

The feature privilegeEscalation is allowed by restricted but not by restricted-v2. More features are denied by restricted-v2 than were allowed by restricted SCC.

A workload with privilegeEscalation: true may be admitted into a newly installed Red Hat OpenShift Container Platform 4.11 or later cluster. To give access to the restricted SCC to the ServiceAccount running the workload (or any other SCC that can admit this workload) using a RoleBinding run the following command:

$ oc -n <workload-namespace> adm policy add-scc-to-user <scc-name> -z <serviceaccount_name>

In Red Hat OpenShift Container Platform {product-version} the ability to add the pod annotations seccomp.security.alpha.kubernetes.io/pod: runtime/default and container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default is deprecated.

Creating seccomp profiles

You can use the MachineConfig object to create profiles.

Seccomp can restrict system calls (syscalls) within a container, limiting the access of your application.

Prerequisites

You have cluster admin permissions.
You have created a custom security context constraints (SCC). For more information, see Additional resources.

Procedure

Create the MachineConfig object:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: custom-seccomp
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<hash>
        filesystem: root
        mode: 0644
        path: /var/lib/kubelet/seccomp/seccomp-nostat.json

Setting up the custom seccomp profile

Prerequisite

You have cluster administrator permissions.
You have created a custom security context constraints (SCC). For more information, see "Additional resources".
You have created a custom seccomp profile.

Procedure

Upload your custom seccomp profile to /var/lib/kubelet/seccomp/<custom-name>.json by using the Machine Config. See "Additional resources" for detailed steps.
Update the custom SCC by providing reference to the created custom seccomp profile:
```
seccompProfiles:
- localhost/<custom-name>.json 
```
Provide the name of your custom seccomp profile.

Applying the custom seccomp profile to the workload

Prerequisite

The cluster administrator has set up the custom seccomp profile. For more details, see "Setting up the custom seccomp profile".

Procedure

Apply the seccomp profile to the workload by setting the securityContext.seccompProfile.type field as following:

Example

spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: <custom-name>.json

Provide the name of your custom seccomp profile.

Alternatively, you can use the pod annotations seccomp.security.alpha.kubernetes.io/pod: localhost/<custom-name>.json. However, this method is deprecated in Red Hat OpenShift Container Platform {product-version}.