Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

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

Chapter 7. Security Profiles Operator

7.1. Security Profiles Operator overview
Link kopieren

OpenShift Container Platform Security Profiles Operator (SPO) provides a way to define secure computing (seccomp) profiles and SELinux profiles as custom resources, synchronizing profiles to every node in a given namespace. For the latest updates, see the release notes.

The SPO can distribute custom resources to each node while a reconciliation loop ensures that the profiles stay up-to-date. See Understanding the Security Profiles Operator.

The SPO manages SELinux policies and seccomp profiles for namespaced workloads. For more information, see Enabling the Security Profiles Operator.

You can create seccomp and SELinux profiles, bind policies to pods, record workloads, and synchronize all worker nodes in a namespace.

Use Advanced Security Profile Operator tasks to enable the log enricher, configure webhooks and metrics, or restrict profiles to a single namespace.

Troubleshoot the Security Profiles Operator as needed, or engage Red Hat support.

You can Uninstall the Security Profiles Operator by removing the profiles before removing the Operator.

7.2. Security Profiles Operator release notes
Link kopieren

The Security Profiles Operator provides a way to define secure computing (seccomp) and SELinux profiles as custom resources, synchronizing profiles to every node in a given namespace.

These release notes track the development of the Security Profiles Operator in OpenShift Container Platform.

For an overview of the Security Profiles Operator, see Security Profiles Operator Overview.

7.2.1. Security Profiles Operator 0.9.0
Link kopieren

The following advisory is available for the Security Profiles Operator 0.9.0: RHBA-2025:15655 - OpenShift Security Profiles Operator update

This update manages security profiles as cluster-wide resources rather than namespace resources. To update Security Profiles Operator to a version later than 0.8.6 requires manual migration. For migration instructions, see Security Profiles Operator 0.9.0 Update Migration Guide.

7.2.1.1. Bug fixes
Link kopieren

  • Before this update, the spod pods could fail to start and enter into a 
    CrashLoopBackOff
    state due to an error in parsing the semanage configuration file. This issue is caused by a change to the RHEL 9 image naming convention beginning in OpenShift Container Platform 4.19. (OCPBUGS-55829)
  • Before this update, the Security Profiles Operator would fail to apply a 
    RawSelinuxProfile
    to newly added nodes due to a reconciler type mismatch error. With this update, the operator now correctly handles 
    RawSelinuxProfile
    objects and policies are applied to all nodes as expected. (OCPBUGS-33718)

7.2.2. Security Profiles Operator 0.8.6
Link kopieren

The following advisory is available for the Security Profiles Operator 0.8.6:

This update includes upgraded dependencies in underlying base images.

7.2.3. Security Profiles Operator 0.8.5
Link kopieren

The following advisory is available for the Security Profiles Operator 0.8.5:

7.2.3.1. Bug fixes
Link kopieren

  • When attempting to install the Security Profile Operator from the web console, the option to enable Operator-recommended cluster monitoring was unavailable for the namespace. With this update, you can now enabled Operator-recommend cluster monitoring in the namespace. (OCPBUGS-37794)
  • Previously, the Security Profiles Operator would intermittently be not visible in the OperatorHub, which caused limited access to install the Operator via the web console. With this update, the Security Profiles Operator is present in the OperatorHub.

7.2.4. Security Profiles Operator 0.8.4
Link kopieren

The following advisory is available for the Security Profiles Operator 0.8.4:

This update addresses CVEs in underlying dependencies.

7.2.4.1. New features and enhancements
Link kopieren

7.2.5. Security Profiles Operator 0.8.2
Link kopieren

The following advisory is available for the Security Profiles Operator 0.8.2:

7.2.5.1. Bug fixes
Link kopieren

  • Previously, 
    SELinuxProfile
    objects did not inherit custom attributes from the same namespace. With this update, the issue has now been resolved and 
    SELinuxProfile
    object attributes are inherited from the same namespace as expected. (OCPBUGS-17164)
  • Previously, RawSELinuxProfiles would hang during the creation process and would not reach an 
    Installed
    state. With this update, the issue has been resolved and RawSELinuxProfiles are created successfully. (OCPBUGS-19744)
  • Previously, patching the 
    enableLogEnricher
    to 
    true
    would cause the 
    seccompProfile
     
    log-enricher-trace
    pods to be stuck in a 
    Pending
    state. With this update, 
    log-enricher-trace
    pods reach an 
    Installed
    state as expected. (OCPBUGS-22182)

  • Previously, the Security Profiles Operator generated high cardinality metrics, causing Prometheus pods using high amounts of memory. With this update, the following metrics will no longer apply in the Security Profiles Operator namespace: 

    • rest_client_request_duration_seconds
       
    • rest_client_request_size_bytes
       

    • rest_client_response_size_bytes

      (OCPBUGS-22406)

7.2.6. Security Profiles Operator 0.8.0
Link kopieren

The following advisory is available for the Security Profiles Operator 0.8.0:

7.2.6.1. Bug fixes
Link kopieren

  • Previously, while trying to install Security Profiles Operator in a disconnected cluster, the secure hashes provided were incorrect due to a SHA relabeling issue. With this update, the SHAs provided work consistently with disconnected environments. (OCPBUGS-14404)

7.2.7. Security Profiles Operator 0.7.1
Link kopieren

The following advisory is available for the Security Profiles Operator 0.7.1:

7.2.7.1. New features and enhancements
Link kopieren

  • Security Profiles Operator (SPO) now automatically selects the appropriate 

    selinuxd
    image for RHEL 8- and 9-based RHCOS systems.

    Important

    Users that mirror images for disconnected environments must mirror both 

    selinuxd
    images provided by the Security Profiles Operator.

  • You can now enable memory optimization inside of an 

    spod
    daemon. For more information, see Enabling memory optimization in the spod daemon.

    Note

    SPO memory optimization is not enabled by default.

  • The daemon resource requirements are now configurable. For more information, see Customizing daemon resource requirements.
  • The priority class name is now configurable in the 
    spod
    configuration. For more information, see Setting a custom priority class name for the spod daemon pod.

7.2.7.2. Deprecated and removed features
Link kopieren

  • The default 
    nginx-1.19.1
    seccomp profile is now removed from the Security Profiles Operator deployment.

7.2.7.3. Bug fixes
Link kopieren

  • Previously, a Security Profiles Operator (SPO) SELinux policy did not inherit low-level policy definitions from the container template. If you selected another template, such as net_container, the policy would not work because it required low-level policy definitions that only existed in the container template. This issue occurred when the SPO SELinux policy attempted to translate SELinux policies from the SPO custom format to the Common Intermediate Language (CIL) format. With this update, the container template appends to any SELinux policies that require translation from SPO to CIL. Additionally, the SPO SELinux policy can inherit low-level policy definitions from any supported policy template. (OCPBUGS-12879)

7.2.7.4. Known issue
Link kopieren

  • When uninstalling the Security Profiles Operator, the 
    MutatingWebhookConfiguration
    object is not deleted and must be manually removed. As a workaround, delete the 
    MutatingWebhookConfiguration
    object after uninstalling the Security Profiles Operator. These steps are defined in Uninstalling the Security Profiles Operator. (OCPBUGS-4687)

7.2.8. Security Profiles Operator 0.5.2
Link kopieren

The following advisory is available for the Security Profiles Operator 0.5.2:

This update addresses a CVE in an underlying dependency.

7.2.8.1. Known issue
Link kopieren

  • When uninstalling the Security Profiles Operator, the 
    MutatingWebhookConfiguration
    object is not deleted and must be manually removed. As a workaround, delete the 
    MutatingWebhookConfiguration
    object after uninstalling the Security Profiles Operator. These steps are defined in Uninstalling the Security Profiles Operator. (OCPBUGS-4687)

7.2.9. Security Profiles Operator 0.5.0
Link kopieren

The following advisory is available for the Security Profiles Operator 0.5.0:

7.2.9.1. Known issue
Link kopieren

  • When uninstalling the Security Profiles Operator, the 
    MutatingWebhookConfiguration
    object is not deleted and must be manually removed. As a workaround, delete the 
    MutatingWebhookConfiguration
    object after uninstalling the Security Profiles Operator. These steps are defined in Uninstalling the Security Profiles Operator. (OCPBUGS-4687)

7.3. Security Profiles Operator support
Link kopieren

7.3.1. Security Profiles Operator lifecycle
Link kopieren

The Security Profiles Operator is a "Rolling Stream" Operator, meaning updates are available asynchronously of OpenShift Container Platform releases. For more information, see OpenShift Operator Life Cycles on the Red Hat Customer Portal.

7.3.2. Getting support
Link kopieren

If you experience difficulty with a procedure described in this documentation, or with OpenShift Container Platform in general, visit the Red Hat Customer Portal.

From the Customer Portal, you can:

  • Search or browse through the Red Hat Knowledgebase of articles and solutions relating to Red Hat products.
  • Submit a support case to Red Hat Support.
  • Access other product documentation.

To identify issues with your cluster, you can use Insights in OpenShift Cluster Manager. Insights provides details about issues and, if available, information on how to solve a problem.

If you have a suggestion for improving this documentation or have found an error, submit a Jira issue for the most relevant documentation component. Please provide specific details, such as the section name and OpenShift Container Platform version.

7.4. Understanding the Security Profiles Operator
Link kopieren

OpenShift Container Platform administrators can use the Security Profiles Operator to define increased security measures in clusters.

Important

The Security Profiles Operator supports only Red Hat Enterprise Linux CoreOS (RHCOS) worker nodes. Red Hat Enterprise Linux (RHEL) nodes are not supported.

7.4.1. About Security Profiles
Link kopieren

Security profiles can increase security at the container level in your cluster.

Seccomp security profiles list the syscalls a process can make. Permissions are broader than SELinux, enabling users to restrict operations system-wide, such as 

write
.

SELinux security profiles provide a label-based system that restricts the access and usage of processes, applications, or files in a system. All files in an environment have labels that define permissions. SELinux profiles can define access within a given structure, such as directories.

7.5. Enabling the Security Profiles Operator
Link kopieren

Before you can use the Security Profiles Operator, you must ensure the Operator is deployed in the cluster.

Important

All cluster nodes must have the same release version in order for this Operator to function properly. As an example, for nodes running RHCOS, all nodes must have the same RHCOS version.

Important

The Security Profiles Operator supports only Red Hat Enterprise Linux CoreOS (RHCOS) worker nodes. Red Hat Enterprise Linux (RHEL) nodes are not supported.

Important

The Security Profiles Operator only supports 

x86_64
architecture.

7.5.1. Installing the Security Profiles Operator
Link kopieren

Prerequisites

  • You must have 
    admin
    privileges.

Procedure

  1. In the OpenShift Container Platform web console, navigate to Operators OperatorHub.
  2. Search for the Security Profiles Operator, then click Install.
  3. Keep the default selection of Installation mode and namespace to ensure that the Operator will be installed to the 
    openshift-security-profiles
    namespace.
  4. Click Install.

Verification

To confirm that the installation is successful:

  1. Navigate to the Operators Installed Operators page.
  2. Check that the Security Profiles Operator is installed in the 
    openshift-security-profiles
    namespace and its status is 
    Succeeded
    .

If the Operator is not installed successfully:

  1. Navigate to the Operators Installed Operators page and inspect the 
    Status
    column for any errors or failures.
  2. Navigate to the Workloads Pods page and check the logs in any pods in the 
    openshift-security-profiles
    project that are reporting issues.

7.5.2. Installing the Security Profiles Operator using the CLI
Link kopieren

Prerequisites

  • You must have 
    admin
    privileges.

Procedure

  1. Define a 

    Namespace
    object:

    Example namespace-object.yaml

    apiVersion: v1
kind: Namespace
metadata:
    name: openshift-security-profiles
labels:
  openshift.io/cluster-monitoring: "true"

  2. Create the 

    Namespace
    object: 

    $ oc create -f namespace-object.yaml

  3. Define an 

    OperatorGroup
    object:

    Example operator-group-object.yaml

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: security-profiles-operator
  namespace: openshift-security-profiles

  4. Create the 

    OperatorGroup
    object: 

    $ oc create -f operator-group-object.yaml

  5. Define a 

    Subscription
    object:

    Example subscription-object.yaml

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: security-profiles-operator-sub
  namespace: openshift-security-profiles
spec:
  channel: release-alpha-rhel-8
  installPlanApproval: Automatic
  name: security-profiles-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

  6. Create the 

    Subscription
    object: 

    $ oc create -f subscription-object.yaml
Note

If you are setting the global scheduler feature and enable 

defaultNodeSelector
, you must create the namespace manually and update the annotations of the 
openshift-security-profiles
namespace, or the namespace where the Security Profiles Operator was installed, with 
openshift.io/node-selector: “”
. This removes the default node selector and prevents deployment failures.

Verification

  1. Verify the installation succeeded by inspecting the following CSV file: 

    $ oc get csv -n openshift-security-profiles

  2. Verify that the Security Profiles Operator is operational by running the following command: 

    $ oc get deploy -n openshift-security-profiles

7.5.3. Configuring logging verbosity
Link kopieren

The Security Profiles Operator supports the default logging verbosity of 

0
and an enhanced verbosity of 
1
.

Procedure

  • To enable enhanced logging verbosity, patch the 

    spod
    configuration and adjust the value by running the following command: 

    $ oc -n openshift-security-profiles patch spod \
    spod --type=merge -p '{"spec":{"verbosity":1}}'

    Example output

    securityprofilesoperatordaemon.security-profiles-operator.x-k8s.io/spod patched

7.6. Managing seccomp profiles
Link kopieren

Create and manage seccomp profiles and bind them to workloads.

Important

The Security Profiles Operator supports only Red Hat Enterprise Linux CoreOS (RHCOS) worker nodes. Red Hat Enterprise Linux (RHEL) nodes are not supported.

7.6.1. Creating seccomp profiles
Link kopieren

Use the 

SeccompProfile
object to create profiles. 

SeccompProfile
objects can restrict syscalls within a container, limiting the access of your application.

Procedure

  1. Create a project by running the following command: 

    $ oc new-project my-namespace

  2. Create the 

    SeccompProfile
    object: 

    apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: profile1
spec:
  defaultAction: SCMP_ACT_LOG

The seccomp profile will be saved in 

/var/lib/kubelet/seccomp/operator/<namespace>/<name>.json
.

An 

init
container creates the root directory of the Security Profiles Operator to run the Operator without 
root
group or user ID privileges. A symbolic link is created from the rootless profile storage 
/var/lib/openshift-security-profiles
to the default 
seccomp
root path inside of the kubelet root 
/var/lib/kubelet/seccomp/operator
.

7.6.2. Applying seccomp profiles to a pod
Link kopieren

Create a pod to apply one of the created profiles.

Procedure

  1. Create a pod object that defines a 

    securityContext
    : 

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: operator/profile1.json
  containers:
    - name: test-container
      image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21

  2. View the profile path of the 

    seccompProfile.localhostProfile
    attribute by running the following command: 

    $ oc get seccompprofile profile1 --output wide

    Example output

    NAME       STATUS     AGE   SECCOMPPROFILE.LOCALHOSTPROFILE
profile1   Installed  14s   operator/profile1.json

  3. View the path to the localhost profile by running the following command: 

    $ oc get sp profile1 --output=jsonpath='{.status.localhostProfile}'

    Example output

    operator/profile1.json

  4. Apply the 

    localhostProfile
    output to the patch file: 

    spec:
  template:
    spec:
      securityContext:
        seccompProfile:
          type: Localhost
          localhostProfile: operator/profile1.json

  5. Apply the profile to any other workload, such as a 

    Deployment
    object, by running the following command: 

    $ oc -n my-namespace patch deployment myapp --patch-file patch.yaml --type=merge

    Example output

    deployment.apps/myapp patched

Verification

  • Confirm the profile was applied correctly by running the following command: 

    $ oc -n my-namespace get deployment myapp --output=jsonpath='{.spec.template.spec.securityContext}' | jq .

    Example output

    {
  "seccompProfile": {
    "localhostProfile": "operator/profile1.json",
    "type": "localhost"
  }
}

7.6.2.1. Binding workloads to profiles with ProfileBindings
Link kopieren

You can use the 

ProfileBinding
resource to bind a security profile to the 
SecurityContext
of a container.

Procedure

  1. To bind a pod that uses a 

    quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    image to the example 
    SeccompProfile
    profile, create a 
    ProfileBinding
    object in the same namespace with the pod and the 
    SeccompProfile
    objects: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileBinding
metadata:
  namespace: my-namespace
  name: nginx-binding
spec:
  profileRef:
    kind: SeccompProfile
    1 
    
    name: profile
    2 
    
  image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    3
    1
    The kind: variable refers to the kind of the profile.
    2
    The name: variable refers to the name of the profile.
    3
    You can enable a default security profile by using a wildcard in the image attribute: image: "*"
    Important

    Using the 

    image: "*"
    wildcard attribute binds all new pods with a default security profile in a given namespace.

  2. Label the namespace with 

    enable-binding=true
    by running the following command: 

    $ oc label ns my-namespace spo.x-k8s.io/enable-binding=true

  3. Define a pod named 

    test-pod.yaml
    : 

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21

  4. Create the pod: 

    $ oc create -f test-pod.yaml
    Note

    If the pod already exists, you must re-create the pod for the binding to work properly.

Verification

  • Confirm the pod inherits the 

    ProfileBinding
    by running the following command: 

    $ oc get pod test-pod -o jsonpath='{.spec.containers[*].securityContext.seccompProfile}'

    Example output

    {"localhostProfile":"operator/profile.json","type":"Localhost"}

7.6.3. Recording profiles from workloads
Link kopieren

The Security Profiles Operator can record system calls with 

ProfileRecording
objects, making it easier to create baseline profiles for applications.

When using the log enricher for recording seccomp profiles, verify the log enricher feature is enabled. See Additional resources for more information.

Note

A container with 

privileged: true
security context restraints prevents log-based recording. Privileged containers are not subject to seccomp policies, and log-based recording makes use of a special seccomp profile to record events.

Procedure

  1. Create a project by running the following command: 

    $ oc new-project my-namespace

  2. Label the namespace with 

    enable-recording=true
    by running the following command: 

    $ oc label ns my-namespace spo.x-k8s.io/enable-recording=true

  3. Create a 

    ProfileRecording
    object containing a 
    recorder: logs
    variable: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  namespace: my-namespace
  name: test-recording
spec:
  kind: SeccompProfile
  recorder: logs
  podSelector:
    matchLabels:
      app: my-app

  4. Create a workload to record: 

    apiVersion: v1
kind: Pod
metadata:
  namespace: my-namespace
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
    - name: nginx
      image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
      ports:
        - containerPort: 8080
    - name: redis
      image: quay.io/security-profiles-operator/redis:6.2.1

  5. Confirm the pod is in a 

    Running
    state by entering the following command: 

    $ oc -n my-namespace get pods

    Example output

    NAME     READY   STATUS    RESTARTS   AGE
my-pod   2/2     Running   0          18s

  6. Confirm the enricher indicates that it receives audit logs for those containers: 

    $ oc -n openshift-security-profiles logs --since=1m --selector name=spod -c log-enricher

    Example output

    I0523 14:19:08.747313  430694 enricher.go:445] log-enricher "msg"="audit" "container"="redis" "executable"="/usr/local/bin/redis-server" "namespace"="my-namespace" "node"="xiyuan-23-5g2q9-worker-eastus2-6rpgf" "pid"=656802 "pod"="my-pod" "syscallID"=0 "syscallName"="read" "timestamp"="1684851548.745:207179" "type"="seccomp"

Verification

  1. Remove the pod: 

    $ oc -n my-namespace delete pod my-pod

  2. Confirm the Security Profiles Operator reconciles the two seccomp profiles: 

    $ oc get seccompprofiles -lspo.x-k8s.io/recording-id=test-recording

    Example output for seccompprofile

    NAME                   STATUS      AGE
test-recording-nginx   Installed   2m48s
test-recording-redis   Installed   2m48s

7.6.3.1. Merging per-container profile instances
Link kopieren

By default, each container instance records into a separate profile. The Security Profiles Operator can merge the per-container profiles into a single profile. Merging profiles is useful when deploying applications using 

ReplicaSet
or 
Deployment
objects.

Procedure

  1. Edit a 

    ProfileRecording
    object to include a 
    mergeStrategy: containers
    variable: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  # The name of the Recording is the same as the resulting SeccompProfile CRD
  # after reconciliation.
  name: test-recording
  namespace: my-namespace
spec:
  kind: SeccompProfile
  recorder: logs
  mergeStrategy: containers
  podSelector:
    matchLabels:
      app: sp-record

  2. Label the namespace by running the following command: 

    $ oc label ns my-namespace security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite=true

  3. Create the workload with the following YAML: 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: my-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sp-record
  template:
    metadata:
      labels:
        app: sp-record
    spec:
      serviceAccountName: spo-record-sa
      containers:
      - name: nginx-record
        image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
        ports:
        - containerPort: 8080

  4. To record the individual profiles, delete the deployment by running the following command: 

    $ oc delete deployment nginx-deploy -n my-namespace

  5. To merge the profiles, delete the profile recording by running the following command: 

    $ oc delete profilerecording test-recording -n my-namespace

  6. To start the merge operation and generate the results profile, run the following command: 

    $ oc get seccompprofiles -lspo.x-k8s.io/recording-id=test-recording -n my-namespace

    Example output for seccompprofiles

    NAME                          STATUS       AGE
test-recording-nginx-record   Installed    55s

  7. To view the permissions used by any of the containers, run the following command: 

    $ oc get seccompprofiles test-recording-nginx-record -o yaml

7.7. Managing SELinux profiles
Link kopieren

Create and manage SELinux profiles and bind them to workloads.

Important

The Security Profiles Operator supports only Red Hat Enterprise Linux CoreOS (RHCOS) worker nodes. Red Hat Enterprise Linux (RHEL) nodes are not supported.

7.7.1. Creating SELinux profiles
Link kopieren

Use the 

SelinuxProfile
object to create profiles.

The 

SelinuxProfile
object has several features that allow for better security hardening and readability:

  • Restricts the profiles to inherit from to the current namespace or a system-wide profile. Because there are typically many profiles installed on the system, but only a subset should be used by cluster workloads, the inheritable system profiles are listed in the 
    spod
    instance in 
    spec.selinuxOptions.allowedSystemProfiles
    .
  • Performs basic validation of the permissions, classes and labels.
  • Adds a new keyword 
    @self
    that describes the process using the policy. This allows reusing a policy between workloads and namespaces easily, as the usage of the policy is based on the name and namespace.
  • Adds features for better security hardening and readability compared to writing a profile directly in the SELinux CIL language.

Procedure

  1. Create a project by running the following command: 

    $ oc new-project nginx-deploy

  2. Create a policy that can be used with a non-privileged workload by creating the following 

    SelinuxProfile
    object: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha2
kind: SelinuxProfile
metadata:
  name: nginx-secure
spec:
  allow:
    '@self':
      tcp_socket:
      - listen
    http_cache_port_t:
      tcp_socket:
      - name_bind
    node_t:
      tcp_socket:
      - node_bind
  inherit:
  - kind: System
    name: container

  3. Wait for 

    selinuxd
    to install the policy by running the following command: 

    $ oc wait --for=condition=ready selinuxprofile nginx-secure

    Example output

    selinuxprofile.security-profiles-operator.x-k8s.io/nginx-secure condition met

    The policies are placed into an 

    emptyDir
    in the container owned by the Security Profiles Operator. The policies are saved in Common Intermediate Language (CIL) format in 
    /etc/selinux.d/<name>_<namespace>.cil
    .

  4. Access the pod by running the following command: 

    $ oc -n openshift-security-profiles rsh -c selinuxd ds/spod

Verification

  1. View the file contents with 

    cat
    by running the following command: 

    $ cat /etc/selinux.d/nginx-secure.cil

    Example output

    (block nginx-secure
(blockinherit container)
(allow process nginx-secure.process ( tcp_socket ( listen )))
(allow process http_cache_port_t ( tcp_socket ( name_bind )))
(allow process node_t ( tcp_socket ( node_bind )))
)

  2. Verify that a policy has been installed by running the following command: 

    $ semodule -l | grep nginx-secure

    Example output

    nginx-secure

7.7.2. Applying SELinux profiles to a pod
Link kopieren

Create a pod to apply one of the created profiles.

For SELinux profiles, the namespace must be labelled to allow privileged workloads.

Procedure

  1. Apply the 

    scc.podSecurityLabelSync=false
    label to the 
    nginx-deploy
    namespace by running the following command: 

    $ oc label ns nginx-deploy security.openshift.io/scc.podSecurityLabelSync=false

  2. Apply the 

    privileged
    label to the 
    nginx-deploy
    namespace by running the following command: 

    $ oc label ns nginx-deploy --overwrite=true pod-security.kubernetes.io/enforce=privileged

  3. Obtain the SELinux profile usage string by running the following command: 

    $ oc get selinuxprofile.security-profiles-operator.x-k8s.io/nginx-secure -ojsonpath='{.status.usage}'

    Example output

    nginx-secure.process

  4. Apply the output string in the workload manifest in the 

    .spec.containers[].securityContext.seLinuxOptions
    attribute: 

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-secure
  namespace: nginx-deploy
spec:
  containers:
    - image: nginxinc/nginx-unprivileged:1.21
      name: nginx
      securityContext:
        seLinuxOptions:
          # NOTE: This uses an appropriate SELinux type
          type: nginx-secure.process
    Important

    The SELinux 

    type
    must exist before creating the workload.

7.7.2.1. Applying SELinux log policies
Link kopieren

To log policy violations or AVC denials, set the 

SElinuxProfile
profile to 
permissive
.

Important

This procedure defines logging policies. It does not set enforcement policies.

Procedure

  • Add 

    permissive: true
    to an 
    SElinuxProfile
    : 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha2
kind: SelinuxProfile
metadata:
  name: nginx-secure
spec:
  permissive: true

7.7.2.2. Binding workloads to profiles with ProfileBindings
Link kopieren

You can use the 

ProfileBinding
resource to bind a security profile to the 
SecurityContext
of a container.

Procedure

  1. To bind a pod that uses a 

    quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    image to the example 
    SelinuxProfile
    profile, create a 
    ProfileBinding
    object in the same namespace with the pod and the 
    SelinuxProfile
    objects: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileBinding
metadata:
  namespace: my-namespace
  name: nginx-binding
spec:
  profileRef:
    kind: SelinuxProfile
    1 
    
    name: profile
    2 
    
  image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    3
    1
    The kind: variable refers to the kind of the profile.
    2
    The name: variable refers to the name of the profile.
    3
    You can enable a default security profile by using a wildcard in the image attribute: image: "*"
    Important

    Using the 

    image: "*"
    wildcard attribute binds all new pods with a default security profile in a given namespace.

  2. Label the namespace with 

    enable-binding=true
    by running the following command: 

    $ oc label ns my-namespace spo.x-k8s.io/enable-binding=true

  3. Define a pod named 

    test-pod.yaml
    : 

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21

  4. Create the pod: 

    $ oc create -f test-pod.yaml
    Note

    If the pod already exists, you must re-create the pod for the binding to work properly.

Verification

  • Confirm the pod inherits the 

    ProfileBinding
    by running the following command: 

    $ oc get pod test-pod -o jsonpath='{.spec.containers[*].securityContext.seLinuxOptions.type}'

    Example output

    profile.process

7.7.2.3. Replicating controllers and SecurityContextConstraints
Link kopieren

When you deploy SELinux policies for replicating controllers, such as deployments or daemon sets, note that the 

Pod
objects spawned by the controllers are not running with the identity of the user who creates the workload. Unless a 
ServiceAccount
is selected, the pods might revert to using a restricted 
SecurityContextConstraints
(SCC) which does not allow use of custom security policies.

Procedure

  1. Create a project by running the following command: 

    $ oc new-project nginx-secure

  2. Create the following 

    RoleBinding
    object to allow SELinux policies to be used in the 
    nginx-secure
    namespace: 

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: spo-nginx
  namespace: nginx-secure
subjects:
- kind: ServiceAccount
  name: spo-deploy-test
roleRef:
  kind: Role
  name: spo-nginx
  apiGroup: rbac.authorization.k8s.io

  3. Create the 

    Role
    object: 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: spo-nginx
  namespace: nginx-secure
rules:
- apiGroups:
  - security.openshift.io
  resources:
  - securitycontextconstraints
  resourceNames:
  - privileged
  verbs:
  - use

  4. Create the 

    ServiceAccount
    object: 

    apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: null
  name: spo-deploy-test
  namespace: nginx-secure

  5. Create the 

    Deployment
    object: 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: selinux-test
  namespace: nginx-secure
  metadata:
    labels:
      app: selinux-test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: selinux-test
  template:
    metadata:
      labels:
        app: selinux-test
    spec:
      serviceAccountName: spo-deploy-test
      securityContext:
        seLinuxOptions:
          type: nginx-secure.process
    1 
    
      containers:
      - name: nginx-unpriv
        image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
        ports:
        - containerPort: 8080
    1
    The .seLinuxOptions.type must exist before the Deployment is created.
    Note

    The SELinux type is not specified in the workload and is handled by the SCC. When the pods are created by the deployment and the 

    ReplicaSet
    , the pods will run with the appropriate profile.

Ensure that your SCC is usable by only the correct service account. Refer to Additional resources for more information.

7.7.3. Recording profiles from workloads
Link kopieren

The Security Profiles Operator can record system calls with 

ProfileRecording
objects, making it easier to create baseline profiles for applications.

When using the log enricher for recording SELinux profiles, verify the log enricher feature is enabled. See Additional resources for more information.

Note

A container with 

privileged: true
security context restraints prevents log-based recording. Privileged containers are not subject to SELinux policies, and log-based recording makes use of a special SELinux profile to record events.

Procedure

  1. Create a project by running the following command: 

    $ oc new-project my-namespace

  2. Label the namespace with 

    enable-recording=true
    by running the following command: 

    $ oc label ns my-namespace spo.x-k8s.io/enable-recording=true

  3. Create a 

    ProfileRecording
    object containing a 
    recorder: logs
    variable: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  namespace: my-namespace
  name: test-recording
spec:
  kind: SelinuxProfile
  recorder: logs
  podSelector:
    matchLabels:
      app: my-app

  4. Create a workload to record: 

    apiVersion: v1
kind: Pod
metadata:
  namespace: my-namespace
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
    - name: nginx
      image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
      ports:
        - containerPort: 8080
    - name: redis
      image: quay.io/security-profiles-operator/redis:6.2.1

  5. Confirm the pod is in a 

    Running
    state by entering the following command: 

    $ oc -n my-namespace get pods

    Example output

    NAME     READY   STATUS    RESTARTS   AGE
my-pod   2/2     Running   0          18s

  6. Confirm the enricher indicates that it receives audit logs for those containers: 

    $ oc -n openshift-security-profiles logs --since=1m --selector name=spod -c log-enricher

    Example output

    I0517 13:55:36.383187  348295 enricher.go:376] log-enricher "msg"="audit" "container"="redis" "namespace"="my-namespace" "node"="ip-10-0-189-53.us-east-2.compute.internal" "perm"="name_bind" "pod"="my-pod" "profile"="test-recording_redis_6kmrb_1684331729" "scontext"="system_u:system_r:selinuxrecording.process:s0:c4,c27" "tclass"="tcp_socket" "tcontext"="system_u:object_r:redis_port_t:s0" "timestamp"="1684331735.105:273965" "type"="selinux"

Verification

  1. Remove the pod: 

    $ oc -n my-namespace delete pod my-pod

  2. Confirm the Security Profiles Operator reconciles the two SELinux profiles: 

    $ oc get selinuxprofiles -lspo.x-k8s.io/recording-id=test-recording

    Example output for selinuxprofile

    NAME                   USAGE                                 STATE
test-recording-nginx   test-recording-nginx.process   Installed
test-recording-redis   test-recording-redis.process   Installed

7.7.3.1. Merging per-container profile instances
Link kopieren

By default, each container instance records into a separate profile. The Security Profiles Operator can merge the per-container profiles into a single profile. Merging profiles is useful when deploying applications using 

ReplicaSet
or 
Deployment
objects.

Procedure

  1. Edit a 

    ProfileRecording
    object to include a 
    mergeStrategy: containers
    variable: 

    apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  # The name of the Recording is the same as the resulting SelinuxProfile CRD
  # after reconciliation.
  name: test-recording
  namespace: my-namespace
spec:
  kind: SelinuxProfile
  recorder: logs
  mergeStrategy: containers
  podSelector:
    matchLabels:
      app: sp-record

  2. Label the namespace by running the following command: 

    $ oc label ns my-namespace security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite=true

  3. Create the workload with the following YAML: 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: my-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sp-record
  template:
    metadata:
      labels:
        app: sp-record
    spec:
      serviceAccountName: spo-record-sa
      containers:
      - name: nginx-record
        image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
        ports:
        - containerPort: 8080

  4. To record the individual profiles, delete the deployment by running the following command: 

    $ oc delete deployment nginx-deploy -n my-namespace

  5. To merge the profiles, delete the profile recording by running the following command: 

    $ oc delete profilerecording test-recording -n my-namespace

  6. To start the merge operation and generate the results profile, run the following command: 

    $ oc get selinuxprofiles -lspo.x-k8s.io/recording-id=test-recording -n my-namespace

    Example output for selinuxprofiles

    NAME                          USAGE                            STATE
test-recording-nginx-record   test-recording-nginx-record.process   Installed

  7. To view the permissions used by any of the containers, run the following command: 

    $ oc get selinuxprofiles test-recording-nginx-record -o yaml

7.7.3.2. About seLinuxContext: RunAsAny
Link kopieren

Recording of SELinux policies is implemented with a webhook that injects a special SELinux type to the pods being recorded. The SELinux type makes the pod run in 

permissive
mode, logging all the AVC denials into 
audit.log
. By default, a workload is not allowed to run with a custom SELinux policy, but uses an auto-generated type.

To record a workload, the workload must use a service account that has permissions to use an SCC that allows the webhook to inject the permissive SELinux type. The 

privileged
SCC contains 
seLinuxContext: RunAsAny
.

In addition, the namespace must be labeled with 

pod-security.kubernetes.io/enforce: privileged
if your cluster enables the Pod Security Admission because only the 
privileged
Pod Security Standard allows using a custom SELinux policy.

7.8. Advanced Security Profiles Operator tasks
Link kopieren

Use advanced tasks to enable metrics, configure webhooks, or restrict syscalls.

7.8.1. Restrict the allowed syscalls in seccomp profiles
Link kopieren

The Security Profiles Operator does not restrict 

syscalls
in 
seccomp
profiles by default. You can define the list of allowed 
syscalls
in the 
spod
configuration.

Procedure

  • To define the list of 

    allowedSyscalls
    , adjust the 
    spec
    parameter by running the following command: 

    $ oc -n openshift-security-profiles patch spod spod --type merge \
    -p '{"spec":{"allowedSyscalls": ["exit", "exit_group", "futex", "nanosleep"]}}'
Important

The Operator will install only the 

seccomp
profiles, which have a subset of 
syscalls
defined into the allowed list. All profiles not complying with this ruleset are rejected.

When the list of allowed 

syscalls
is modified in the 
spod
configuration, the Operator will identify the already installed profiles which are non-compliant and remove them automatically.

7.8.2. Base syscalls for a container runtime
Link kopieren

You can use the 

baseProfileName
attribute to establish the minimum required 
syscalls
for a given runtime to start a container.

Procedure

  • Edit the 

    SeccompProfile
    kind object and add 
    baseProfileName: runc-v1.0.0
    to the 
    spec
    field: 

    apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: example-name
spec:
  defaultAction: SCMP_ACT_ERRNO
  baseProfileName: runc-v1.0.0
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - exit_group

7.8.3. Enabling memory optimization in the spod daemon
Link kopieren

The controller running inside of 

spod
daemon process watches all pods available in the cluster when profile recording is enabled. This can lead to very high memory usage in large clusters, resulting in the 
spod
daemon running out of memory or crashing.

To prevent crashes, the 

spod
daemon can be configured to only load the pods labeled for profile recording into the cache memory.

+

Note

SPO memory optimization is not enabled by default.

Procedure

  1. Enable memory optimization by running the following command: 

    $ oc -n openshift-security-profiles patch spod spod --type=merge -p '{"spec":{"enableMemoryOptimization":true}}'

  2. To record a security profile for a pod, the pod must be labeled with 

    spo.x-k8s.io/enable-recording: "true"
    : 

    apiVersion: v1
kind: Pod
metadata:
  name: my-recording-pod
  labels:
    spo.x-k8s.io/enable-recording: "true"

7.8.4. Customizing daemon resource requirements
Link kopieren

The default resource requirements of the daemon container can be adjusted by using the field 

daemonResourceRequirements
from the 
spod
configuration.

Procedure

  • To specify the memory and cpu requests and limits of the daemon container, run the following command: 

    $ oc -n openshift-security-profiles patch spod spod --type merge -p \
    '{"spec":{"daemonResourceRequirements": { \
    "requests": {"memory": "256Mi", "cpu": "250m"}, \
    "limits": {"memory": "512Mi", "cpu": "500m"}}}}'

7.8.5. Setting a custom priority class name for the spod daemon pod
Link kopieren

The default priority class name of the 

spod
daemon pod is set to 
system-node-critical
. A custom priority class name can be configured in the 
spod
configuration by setting a value in the 
priorityClassName
field.

Procedure

  • Configure the priority class name by running the following command: 

    $ oc -n openshift-security-profiles patch spod spod --type=merge -p '{"spec":{"priorityClassName":"my-priority-class"}}'

    Example output

    securityprofilesoperatordaemon.openshift-security-profiles.x-k8s.io/spod patched

7.8.6. Using metrics
Link kopieren

The 

openshift-security-profiles
namespace provides metrics endpoints, which are secured by the kube-rbac-proxy container. All metrics are exposed by the 
metrics
service within the 
openshift-security-profiles
namespace.

The Security Profiles Operator includes a cluster role and corresponding binding 

spo-metrics-client
to retrieve the metrics from within the cluster. There are two metrics paths available: 

  • metrics.openshift-security-profiles/metrics
    : for controller runtime metrics 
  • metrics.openshift-security-profiles/metrics-spod
    : for the Operator daemon metrics

Procedure

  1. To view the status of the metrics service, run the following command: 

    $ oc get svc/metrics -n openshift-security-profiles

    Example output

    NAME      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
metrics   ClusterIP   10.0.0.228   <none>        443/TCP   43s

  2. To retrieve the metrics, query the service endpoint using the default 

    ServiceAccount
    token in the 
    openshift-security-profiles
    namespace by running the following command: 

    $ oc run --rm -i --restart=Never --image=registry.fedoraproject.org/fedora-minimal:latest \
    -n openshift-security-profiles metrics-test -- bash -c \
    'curl -ks -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://metrics.openshift-security-profiles/metrics-spod'

    Example output

    # HELP security_profiles_operator_seccomp_profile_total Counter about seccomp profile operations.
# TYPE security_profiles_operator_seccomp_profile_total counter
security_profiles_operator_seccomp_profile_total{operation="delete"} 1
security_profiles_operator_seccomp_profile_total{operation="update"} 2

  3. To retrieve metrics from a different namespace, link the 

    ServiceAccount
    to the 
    spo-metrics-client
     
    ClusterRoleBinding
    by running the following command: 

    $ oc get clusterrolebinding spo-metrics-client -o wide

    Example output

    NAME                 ROLE                             AGE   USERS   GROUPS   SERVICEACCOUNTS
spo-metrics-client   ClusterRole/spo-metrics-client   35m                    openshift-security-profiles/default

7.8.6.1. controller-runtime metrics
Link kopieren

The controller-runtime 

metrics
and the DaemonSet endpoint 
metrics-spod
provide a set of default metrics. Additional metrics are provided by the daemon, which are always prefixed with 
security_profiles_operator_
.

Expand
Table 7.1. Available controller-runtime metrics
Metric keyPossible labelsTypePurpose

seccomp_profile_total
 

operation={delete,update}

Counter

Amount of seccomp profile operations. 

seccomp_profile_audit_total
 

node
, 
namespace
, 
pod
, 
container
, 
executable
, 
syscall

Counter

Amount of seccomp profile audit operations. Requires the log enricher to be enabled. 

seccomp_profile_bpf_total
 

node
, 
mount_namespace
, 
profile

Counter

Amount of seccomp profile bpf operations. Requires the bpf recorder to be enabled. 

seccomp_profile_error_total
 

reason={
 

SeccompNotSupportedOnNode,
 

InvalidSeccompProfile,
 

CannotSaveSeccompProfile,
 

CannotRemoveSeccompProfile,
 

CannotUpdateSeccompProfile,
 

CannotUpdateNodeStatus
 

}

Counter

Amount of seccomp profile errors. 

selinux_profile_total
 

operation={delete,update}

Counter

Amount of SELinux profile operations. 

selinux_profile_audit_total
 

node
, 
namespace
, 
pod
, 
container
, 
executable
, 
scontext
,
tcontext

Counter

Amount of SELinux profile audit operations. Requires the log enricher to be enabled. 

selinux_profile_error_total
 

reason={
 

CannotSaveSelinuxPolicy,
 

CannotUpdatePolicyStatus,
 

CannotRemoveSelinuxPolicy,
 

CannotContactSelinuxd,
 

CannotWritePolicyFile,
 

CannotGetPolicyStatus
 

}

Counter

Amount of SELinux profile errors.

7.8.7. Using the log enricher
Link kopieren

The Security Profiles Operator contains a log enrichment feature, which is disabled by default. The log enricher container runs with 

privileged
permissions to read the audit logs from the local node. The log enricher runs within the host PID namespace, 
hostPID
.

Important

The log enricher must have permissions to read the host processes.

Procedure

  1. Patch the 

    spod
    configuration to enable the log enricher by running the following command: 

    $ oc -n openshift-security-profiles patch spod spod \
    --type=merge -p '{"spec":{"enableLogEnricher":true}}'

    Example output

    securityprofilesoperatordaemon.security-profiles-operator.x-k8s.io/spod patched

    Note

    The Security Profiles Operator will re-deploy the 

    spod
    daemon set automatically.

  2. View the audit logs by running the following command: 

    $ oc -n openshift-security-profiles logs -f ds/spod log-enricher

    Example output

    I0623 12:51:04.257814 1854764 deleg.go:130] setup "msg"="starting component: log-enricher"  "buildDate"="1980-01-01T00:00:00Z" "compiler"="gc" "gitCommit"="unknown" "gitTreeState"="clean" "goVersion"="go1.16.2" "platform"="linux/amd64" "version"="0.4.0-dev"
I0623 12:51:04.257890 1854764 enricher.go:44] log-enricher "msg"="Starting log-enricher on node: 127.0.0.1"
I0623 12:51:04.257898 1854764 enricher.go:46] log-enricher "msg"="Connecting to local GRPC server"
I0623 12:51:04.258061 1854764 enricher.go:69] log-enricher "msg"="Reading from file /var/log/audit/audit.log"
2021/06/23 12:51:04 Seeked /var/log/audit/audit.log - &{Offset:0 Whence:2}

7.8.7.1. Using the log enricher to trace an application
Link kopieren

You can use the Security Profiles Operator log enricher to trace an application.

Procedure

  1. To trace an application, create a 

    SeccompProfile
    logging profile: 

    apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: log
spec:
  defaultAction: SCMP_ACT_LOG

  2. Create a pod object to use the profile: 

    apiVersion: v1
kind: Pod
metadata:
  name: log-pod
  namespace: default
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: operator/log.json
  containers:
    - name: log-container
      image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21

  3. Examine the log enricher output by running the following command: 

    $ oc -n openshift-security-profiles logs -f ds/spod log-enricher

    Example 7.1. Example output

    …
I0623 12:59:11.479869 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=3 "syscallName"="close" "timestamp"="1624453150.205:1061" "type"="seccomp"
I0623 12:59:11.487323 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=157 "syscallName"="prctl" "timestamp"="1624453150.205:1062" "type"="seccomp"
I0623 12:59:11.492157 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=157 "syscallName"="prctl" "timestamp"="1624453150.205:1063" "type"="seccomp"
…
I0623 12:59:20.258523 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=12 "syscallName"="brk" "timestamp"="1624453150.235:2873" "type"="seccomp"
I0623 12:59:20.263349 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=21 "syscallName"="access" "timestamp"="1624453150.235:2874" "type"="seccomp"
I0623 12:59:20.354091 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=257 "syscallName"="openat" "timestamp"="1624453150.235:2875" "type"="seccomp"
I0623 12:59:20.358844 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=5 "syscallName"="fstat" "timestamp"="1624453150.235:2876" "type"="seccomp"
I0623 12:59:20.363510 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=9 "syscallName"="mmap" "timestamp"="1624453150.235:2877" "type"="seccomp"
I0623 12:59:20.454127 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=3 "syscallName"="close" "timestamp"="1624453150.235:2878" "type"="seccomp"
I0623 12:59:20.458654 1854764 enricher.go:111] log-enricher "msg"="audit"  "container"="log-container" "executable"="/usr/sbin/nginx" "namespace"="default" "node"="127.0.0.1" "pid"=1905792 "pod"="log-pod" "syscallID"=257 "syscallName"="openat" "timestamp"="1624453150.235:2879" "type"="seccomp"
…

7.8.8. Configuring webhooks
Link kopieren

Profile binding and profile recording objects can use webhooks. Profile binding and recording object configurations are 

MutatingWebhookConfiguration
CRs, managed by the Security Profiles Operator.

To change the webhook configuration, the 

spod
CR exposes a 
webhookOptions
field that allows modification of the 
failurePolicy
, 
namespaceSelector
, and 
objectSelector
variables. This allows you to set the webhooks to "soft-fail" or restrict them to a subset of a namespaces so that even if the webhooks failed, other namespaces or resources are not affected.

Procedure

  1. Set the 

    recording.spo.io
    webhook configuration to record only pods labeled with 
    spo-record=true
    by creating the following patch file: 

    spec:
  webhookOptions:
    - name: recording.spo.io
      objectSelector:
        matchExpressions:
          - key: spo-record
            operator: In
            values:
              - "true"

  2. Patch the 

    spod/spod
    instance by running the following command: 

    $ oc -n openshift-security-profiles patch spod \
    spod -p $(cat /tmp/spod-wh.patch) --type=merge

  3. To view the resulting 

    MutatingWebhookConfiguration
    object, run the following command: 

    $ oc get MutatingWebhookConfiguration \
    spo-mutating-webhook-configuration -oyaml

7.9. Troubleshooting the Security Profiles Operator
Link kopieren

Troubleshoot the Security Profiles Operator to diagnose a problem or provide information in a bug report.

7.9.1. Inspecting seccomp profiles
Link kopieren

Corrupted 

seccomp
profiles can disrupt your workloads. Ensure that the user cannot abuse the system by not allowing other workloads to map any part of the path 
/var/lib/kubelet/seccomp/operator
.

Procedure

  1. Confirm that the profile is reconciled by running the following command: 

    $ oc -n openshift-security-profiles logs openshift-security-profiles-<id>

    Example 7.2. Example output

    I1019 19:34:14.942464       1 main.go:90] setup "msg"="starting openshift-security-profiles"  "buildDate"="2020-10-19T19:31:24Z" "compiler"="gc" "gitCommit"="a3ef0e1ea6405092268c18f240b62015c247dd9d" "gitTreeState"="dirty" "goVersion"="go1.15.1" "platform"="linux/amd64" "version"="0.2.0-dev"
I1019 19:34:15.348389       1 listener.go:44] controller-runtime/metrics "msg"="metrics server is starting to listen"  "addr"=":8080"
I1019 19:34:15.349076       1 main.go:126] setup "msg"="starting manager"
I1019 19:34:15.349449       1 internal.go:391] controller-runtime/manager "msg"="starting metrics server"  "path"="/metrics"
I1019 19:34:15.350201       1 controller.go:142] controller "msg"="Starting EventSource" "controller"="profile" "reconcilerGroup"="security-profiles-operator.x-k8s.io" "reconcilerKind"="SeccompProfile" "source"={"Type":{"metadata":{"creationTimestamp":null},"spec":{"defaultAction":""}}}
I1019 19:34:15.450674       1 controller.go:149] controller "msg"="Starting Controller" "controller"="profile" "reconcilerGroup"="security-profiles-operator.x-k8s.io" "reconcilerKind"="SeccompProfile"
I1019 19:34:15.450757       1 controller.go:176] controller "msg"="Starting workers" "controller"="profile" "reconcilerGroup"="security-profiles-operator.x-k8s.io" "reconcilerKind"="SeccompProfile" "worker count"=1
I1019 19:34:15.453102       1 profile.go:148] profile "msg"="Reconciled profile from SeccompProfile" "namespace"="openshift-security-profiles" "profile"="nginx-1.19.1" "name"="nginx-1.19.1" "resource version"="728"
I1019 19:34:15.453618       1 profile.go:148] profile "msg"="Reconciled profile from SeccompProfile" "namespace"="openshift-security-profiles" "profile"="openshift-security-profiles" "name"="openshift-security-profiles" "resource version"="729"

  2. Confirm that the 

    seccomp
    profiles are saved into the correct path by running the following command: 

    $ oc exec -t -n openshift-security-profiles openshift-security-profiles-<id> \
    -- ls /var/lib/kubelet/seccomp/operator/my-namespace/my-workload

    Example output

    profile-block.json
profile-complain.json

7.10. Uninstalling the Security Profiles Operator
Link kopieren

You can remove the Security Profiles Operator from your cluster by using the OpenShift Container Platform web console.

7.10.1. Uninstall the Security Profiles Operator using the web console
Link kopieren

To remove the Security Profiles Operator, you must first delete the 

seccomp
and SELinux profiles. After the profiles are removed, you can then remove the Operator and its namespace by deleting the openshift-security-profiles project.

Prerequisites

  • Access to an OpenShift Container Platform cluster that uses an account with 
    cluster-admin
    permissions.
  • The Security Profiles Operator is installed.

Procedure

To remove the Security Profiles Operator by using the OpenShift Container Platform web console:

  1. Navigate to the Operators Installed Operators page.
  2. Delete all 
    seccomp
    profiles, SELinux profiles, and webhook configurations.
  3. Switch to the Administration Operators Installed Operators page.
  4. Click the Options menu kebab on the Security Profiles Operator entry and select Uninstall Operator.
  5. Switch to the Home Projects page.
  6. Search for 
    security profiles
    .

  7. Click the Options menu kebab next to the openshift-security-profiles project, and select Delete Project.

    1. Confirm the deletion by typing 
      openshift-security-profiles
      in the dialog box, and click Delete.

  8. Delete the 

    MutatingWebhookConfiguration
    object by running the following command: 

    $ oc delete MutatingWebhookConfiguration spo-mutating-webhook-configuration
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