Enable the RuntimeDefault seccomp profile in OpenShift for all workloads

Epic Goal

The overall goal of this EPIC is to enable the RuntimeDefault seccomp profile for all workloads in OpenShift by default.

Why is this important?

Seccomp is an important security feature to intercept syscalls and take action of their behavior. Many vulnerabilities could have been prevented if containers would run with an appropriate seccomp profile enabled. The container runtime CRI-O ships a default profile which provides a strong set of default security standards. Right now, every Kubernetes workload runs without seccomp enabled (unconfined) if they do not specify RuntimeDefault within the security context of the pod or container.

Enabling the default profile for every workload in OpenShift will help to raise the security standards of the platform. It also incorporates the risk that workloads running previously unconfined will now break because they did not specify any seccomp security context at all.

Scenarios

There are two feature streams to consider when speaking about this topic:

• The upstream enhancement to enable seccomp by default, which is right now in alpha (disabled by default) stage and should graduate with Kubernetes v1.25:
  https://github.com/kubernetes/enhancements/issues/2413
• The CRI-O feature --seccomp-use-default-when-empty, which is disabled by default.

While enabling the feature itself for OpenShift 4.11 by choosing one of the above streams seems to be trivial, we still have to consider an upgrade path which does not break existing workloads. Therefore we propose to:

1. Enable the feature for 4.11
2. Create a MCO drop in to explicitly disable the feature in 4.10.z
3. Upgrades from 4.10 to 4.11 can optionally remove the drop-in

The above strategy requires that everyone is forced to go through 4.10.z during an upgrade.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Possible upgrade paths have to be fulfilled.

Dependencies (internal and external)

• The MCO team has to be required for additional input on the overall topic
• The OTA team has to be required to help on the upgrade paths

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>