OCI Artifact-Based Security Profile Distribution

This KEP proposes native support for pulling security profiles from OCI-compatible registries, starting with seccomp in alpha and adding AppArmor in beta. Today, Kubernetes requires security profiles to be pre-installed on every node (Localhost type) or limits users to the built-in RuntimeDefault. This creates operational burden for cluster administrators who must distribute and synchronize profiles across all nodes using external tooling such as DaemonSets, node image baking, or the [Security Profiles Operator (SPO)][spo]. [spo]: https://github.com/kubernetes-sigs/security-profiles-operator By extending the Kubernetes API and CRI to support OCI references for security profiles, users can store versioned, immutable profiles in container registries alongside the container images they protect and reference them by digest. The kubelet resolves pull credentials and passes them to the CRI runtime, which pulls the profiles using the same registry infrastructure already in place for container images. The kubelet never inspects the content: how the runtime fetches and stores it is a runtime decision. The design supports a layered profile model: pods can specify both a base profile (Localhost or RuntimeDefault) and an OCI overlay profile. The CRI runtime merges the OCI profile with the base profile and its own configured baseline via intersection, producing an effective profile that is at least as restrictive as every input. This guarantees that OCI-distributed profiles cannot weaken node security regardless of their content, while allowing administrators to enforce per-workload-class baselines without breaking existing OCI profiles when the baseline changes. The converse also holds: an OCI profile can never grant an operation that the node's baseline denies. Workloads that need a profile looser than the baseline continue to use Localhost.