After several years carrying a beta tag, the Kubernetes Security Profiles Operator went 1.0.0 on June 26, freezing eight CRD APIs and clearing a third-party security audit with no criticals. For cluster admins, the practical effect is small but consequential: the syscall and LSM profile a workload runs under is now declared on APIs that will not move under your feet.
The release was announced by Sascha Grunert of Red Hat on the CNCF blog. SPO is the Kubernetes operator that manages seccomp, SELinux and AppArmor profiles as cluster-scoped objects, then attaches them to pods. Until now the value proposition was good and the API was provisional. v1.0.0 nails the second half down.
What's actually stable
All eight CRDs graduated to v1, including SeccompProfile, ProfileRecording, SelinuxProfile, RawSelinuxProfile, and the AppArmor profile type. Conversion webhooks ship with the release, so a cluster running earlier API versions can roll forward without scheduling downtime. The older versions remain available and are slated for removal in a future release. The migration is on the clock, not on fire.
The audit pass came with some shape changes that are worth reading before you upgrade. SelinuxProfile swapped its boolean permissive field for a mode enum with Enforcing and Permissive values, which means any GitOps templates that hard-coded permissive: true need a rewrite. RawSelinuxProfile is now gated by an enableRawSelinuxProfiles configuration flag and a validating admission webhook, so the most privileged path through the operator is off by default. AppArmor inputs run through strict regex validation, raw policy payloads are capped at 500 KB, and the eBPF profile recorder picked up explicit resource limits.
Why a cluster team should care
The point of an operator like this is to take the profile out of the host's filesystem and into the API. That changes the blast radius of "we shipped a container with no profile at all." With SPO and a workload-attached profile, the runtime gets the rules from the cluster, the cluster gets the rules from Git, and a rollback is a kubectl apply away. Without it, a profile change usually means a node image bake, which is slower and harder to undo at 3am.
The v1.0.0 line means platform teams can adopt SPO without writing "subject to API churn" in the runbook. In most platform-engineering shops that was the gating concern, not the technology.
The bet still on the table
KEP 6061, OCI Artifact-Based Security Profile Distribution, is proposed for an upcoming Kubernetes release as alpha. The idea is that kubelet itself learns to fetch profiles from an OCI registry, the same way it already pulls images. If that lands, the cluster no longer needs SPO to deliver the profile to the node; the operator stays useful for authoring and lifecycle, but the distribution path moves into core.
This is the right direction for reliability. It collapses two control planes into one. It also means SPO's own value proposition will sit closer to "compiler and CI for profiles" than "runtime mover of files." Worth tracking before you commit to a long-term operator deployment plan.
Watch list for the upgrade
A few rough edges. The permissive to mode rename is a silent break for any template that does not run through the conversion webhook before write. The default-off posture on RawSelinuxProfile is correct, but teams that relied on it must explicitly opt back in. The upstream KEP is alpha, not GA, so SPO's role in production stays where it is for at least two Kubernetes release cycles.
How other projects approach the same surface is fragmented. Falco watches behavior at runtime and alerts. SPO writes the rule that would block the behavior in the first place. Kyverno and Gatekeeper can enforce that a pod has a profile, but they neither author nor distribute one. The combination most platform teams end up running is SPO for the rules, an admission policy engine for the "must have a profile" guard, and a runtime detector for what slips through.
v1.0.0 makes the SPO half of that stack stable enough to depend on. The KEP decides whether its role grows or shrinks from there.
Top comments (0)