Configuring seccomp profiles

The SCC applies to all newly created pods in 4.13. The default seccomp profile runtime/default is applied to these pods.

Seccomp profiles are stored as JSON files on the disk.

OKD ships with a default seccomp profile that is referenced as runtime/default. In 4.13, newly created pods have the Security Context Constraint (SCC) set to restricted-v2 and the default seccomp profile applies to the pod.

Procedure

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

   1. Verify what pods are running in the 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

   2. Inspect the pods:

      Example output

      apiVersion: v1
      kind: Pod
      metadata:
        annotations:
          k8s.v1.cni.cncf.io/network-status: |-
            [{
                "interface": "eth0",
                "ips": [
                    "10.131.0.18"
                ],
                "default": true,
                "dns": {}
            }]
          k8s.v1.cni.cncf.io/networks-status: |-
            [{
                "name": "openshift-sdn",
                "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
          seccomp.security.alpha.kubernetes.io/pod: runtime/default (2)

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

In clusters upgraded to 4.13 all authenticated users have access to the restricted and restricted-v2 SCC.

A workload admitted by the SCC restricted for example, on a OKD 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.

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 .

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 OKD 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 OKD 4.13 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.

You can configure a custom seccomp profile, which allows you to update the filters based on the application requirements. This allows cluster administrators to have greater control over the security of workloads running in OpenShift Container Platform.

Seccomp security profiles list the system calls (syscalls) a process can make. Permissions are broader than SELinux, which restrict operations, such as write, system-wide.

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:

Prerequisite

• You have cluster administrator permissions.

• You have created a custom security context constraints (SCC). For more information, see “Additional resources”.

Procedure

1. Upload your custom seccomp profile to /var/lib/kubelet/seccomp/<custom-name>.json by using the Machine Config. See “Additional resources” for detailed steps.

2. Update the custom SCC by providing reference to the created custom seccomp profile:

   seccompProfiles:
   - localhost/<custom-name>.json (1)

   1	Provide the name of your custom seccomp profile.

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
  

  Alternatively, you can use the pod annotations seccomp.security.alpha.kubernetes.io/pod: localhost/<custom-name>.json. However, this method is deprecated in OKD 4.13.

During deployment, the admission controller validates the following:

• The annotations against the current SCCs allowed by the user role.

• The SCC, which includes the seccomp profile, is allowed for the pod.

If the SCC is allowed for the pod, the kubelet runs the pod with the specified seccomp profile.