Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 12. Configuring seccomp profiles

An OpenShift Container Platform container or a pod runs a single application that performs one or more well-defined tasks. The application usually requires only a small subset of the underlying operating system kernel APIs. Secure computing mode, seccomp, is a Linux kernel feature that can be used to limit the process running in a container to only using a subset of the available system calls.

The 

restricted-v2
SCC applies to all newly created pods in 4.12. The default seccomp profile 
runtime/default
is applied to these pods.

Seccomp profiles are stored as JSON files on the disk.

Important

Seccomp profiles cannot be applied to privileged containers.

12.1. Verifying the default seccomp profile applied to a pod
Link kopieren

OpenShift Container Platform ships with a default seccomp profile that is referenced as 

runtime/default
. In 4.12, 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: 

      $ 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

    2. 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": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.131.0.18"
          ],
          "default": true,
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/networks-status: |-
      [{
          "name": "openshift-sdn",
          "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
      1 
      
    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.12 will have the seccomp profile configured to runtime/default as mandated by the SCC.

12.1.1. Upgraded cluster
Link kopieren

In clusters upgraded to 4.12 all authenticated users have access to the 

restricted
and 
restricted-v2
SCC.

A workload admitted by the SCC 

restricted
for example, on a 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
.

Note

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
.

12.1.2. Newly installed cluster
Link kopieren

For newly installed 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 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 OpenShift Container Platform 4.12 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.

12.2. Configuring a custom seccomp profile
Link kopieren

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.

12.2.1. Creating seccomp profiles
Link kopieren

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

12.2.2. Setting up the custom seccomp profile
Link kopieren

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

  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.

12.2.3. Applying the custom seccomp profile to the workload
Link kopieren

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
    1

    1
    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 OpenShift Container Platform 4.12.

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.

Important

Ensure that the seccomp profile is deployed to all worker nodes.

Note

The custom SCC must have the appropriate priority to be automatically assigned to the pod or meet other conditions required by the pod, such as allowing CAP_NET_ADMIN.

Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben