# Security Profiles Operator: putting seccomp, SELinux and AppArmor under Kubernetes control > The Kubernetes Security Profiles Operator is an out-of-tree enhancement that lets clusters define seccomp, SELinux and AppArmor profiles as custom resources and installs them on the nodes, with recording, binding to images and audit log enrichment. It suits platform teams who want profiles managed declaratively rather than baked into node images. **kubernetes-sigs/security-profiles-operator** — The Kubernetes Security Profiles Operator - Repository: https://github.com/kubernetes-sigs/security-profiles-operator - Stars: 876 · Forks: 139 - Language: C - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/kubernetes-sigs-security-profiles-operator ## What the operator actually manages on a node The positioning is precise about being an out-of-tree Kubernetes enhancement aimed at making it easier to create and use SELinux, seccomp and AppArmor security profiles in a cluster. The architecture has two pieces. The operator runs as a deployment in the cluster, and it manages daemon pods on each node, and those daemon pods handle profile installation, recording and enforcement for the three profile types. The reason a daemon is needed on each node is that a Linux security profile is a file or an object that the kernel enforces, so the artefact has to land on the machine where the workload will run, and the operator needs to be able to place it there, clean it up later, and tell the node that it is there. The documentation describes the architecture and links the user stories, personas and guides, and the motivation is traced to a design document in the repository with a link to the corresponding enhancement proposal. ## The parity table is the honest summary of what works where The feature table is the most useful thing in the readme, and it is a matrix of capabilities against the three profile types with some cells empty. A profile custom resource definition, installing profiles in the cluster, removing unused profiles from the cluster, binding a profile to container images and audit log enrichment are all supported across seccomp, SELinux and AppArmor. The differences are where the real information is. Profile recording from audit logs is available for seccomp and SELinux but not for AppArmor, while profile recording with eBPF is available for seccomp and AppArmor but not for SELinux, which follows from how each mechanism works underneath. Audit in-pod activity JSON log enrichment is a seccomp only feature. So the choice of profile type is partly a choice of which recording mechanism you can use, and a team that needs both audit log and eBPF recording has to pick one of the two profile types rather than combining them. The documentation points to the security model for what permissions each feature requires, which is the document to read before enabling recording. ## Installing, and why cert-manager shows up first The quick start has three phases. The first is cert-manager, which the documentation says is not needed on OpenShift, applied from the release manifest and then waited on until the deployment is available: ```sh kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml kubectl --namespace cert-manager wait --for condition=available deployment --all ``` The second phase applies the operator manifest from the latest release, with the version given without the v prefix: ```sh VERSION=x.y.z kubectl apply -f "https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/v${VERSION}/deploy/operator.yaml" ``` The third phase waits for the daemon to report a running state, then applies the example seccomp profiles and checks the status, where the output shows four example profiles with an Installed status. The cert-manager dependency comes from the operator's own use of a certificate for its webhook and communication with the node daemon, which is the usual reason a Kubernetes operator drags in cert-manager. The documentation lists four installation methods, the release manifest as used above, a Helm chart attached to each release and published on the registry, the operator lifecycle manager from operatorhub.io or the upstream catalog, and OpenShift through OperatorHub, where the note repeats that OpenShift needs no cert-manager. ## Provenance is treated as a feature, not an afterthought Two details in the build setup show how seriously this project treats supply chain. The released container images are available under a registry path, and there is a separate document on verifying the released artifacts. The dependency list in the Go module is where the evidence sits, since it includes the sigstore family, the transparency log and the TUF update framework, plus an in-toto attestation library, which together are the building blocks of signing and verifying artefacts. There is also a client for the container registry, which is what lets the operator pull and inspect images when binding a profile to one. The build image in the Dockerfile is pinned by digest rather than by tag, and the comment explains why, that a mutable tag means the toolchain that compiles every released binary can be replaced remotely without any change in the repository, and the provenance would still verify. The comment on the Nix configuration is equally pointed, that only the Nix cache may substitute anything, whatever the build image says, because older build images use the project's own cache which CI jobs running repository code write to. ## A large Go codebase with a substantial dependency set The module is the sigs.k8s.io path, which is the conventional location for a Kubernetes project that has not yet graduated, and it asks for Go 1.27 with a matching toolchain. The dependency list is long and it maps the feature set directly. The seccomp side has the seccomp library bindings and the container runtime specification and the runc version, and the AppArmor side has a Go binding for AppArmor. The eBPF side has the libbpf bindings, which is what the eBPF recording mode needs, and the Kubernetes side has the OCI image specification, the digest library and the container registry client. There is also a certificate manager library, a common expression language library, a Prometheus client and the Prometheus operator APIs, and a set of command line and utility packages including a Prometheus model, a JSON patch library and a YAML parser. The repository layout matches a project with several delivery formats, with api, cmd, internal, deploy, doc, examples, hack, nix, test and vendor directories, and a set of Dockerfiles for the build image, the bundle, the catalog and the UBI variant, plus a cloudbuild configuration for the releases. ## Where the project sits in the wider ecosystem The readme names the enhancement proposals that directly influence the work, and those are worth reading because they explain the constraints the operator operates under. They are the proposal to promote seccomp to general availability, the proposal to add ConfigMap support for seccomp custom profiles, and the proposal to create built-in seccomp profiles and add a complain mode. It also lists the existing approaches in the Kubernetes world that predate it, which is a candid admission that this is not the only way to solve the problem. The AppArmor loader is listed, the OpenShift machine config operator which is in charge of file management and security profiles on hosts, and the seccomp-config project. The machine config operator entry is the important one for anyone running OpenShift, because that is the same job done through node configuration, and the operator documentation has a separate OpenShift section. The project also has a monthly meeting on the last Thursday of each month, a Slack channel, a mailing list, a code of conduct that follows the Kubernetes one, and a security policy with a separate security contacts file. The last push was on 2026-10-19, and the release history shows v1.1.1 on 2026-10-05, v1.1.0 on 2026-09-23 and v1.0.1 on 2026-08-26, so the 1.x line is recent and settling. ## Conclusion The Security Profiles Operator is a good fit for a platform team that wants to manage workload security profiles the same way they manage any other Kubernetes resource, and that has clusters where the node image is not under their control. It is the wrong choice if your environment already solves this through node configuration, since the OpenShift machine config operator is listed as an existing approach that does the same job for host file management, and it is the wrong choice if you only need one static profile, since a custom resource definition and a node daemon per node is a lot of machinery for that. It is also the wrong choice if the feature parity gaps matter to you, because the table shows that AppArmor has no audit log recording and SELinux has no eBPF recording, and that in-pod activity JSON enrichment is a seccomp only feature. Before adopting it, read the security model document, because the operator needs substantial node permissions, and check the recording mode you need against the parity table. The project is Apache-2.0 licensed, the last push was on 2026-10-19, and the current release is v1.1.1 from 2026-10-05. ## FAQ ### What does the Kubernetes Security Profiles Operator do? It is an out-of-tree Kubernetes enhancement that makes it easier to create and use SELinux, seccomp and AppArmor security profiles in a cluster. The operator runs as a deployment in the cluster and manages daemon pods on each node, and those daemons handle profile installation, recording and enforcement. ### Which features of the Security Profiles Operator work with all three profile types? The profile custom resource definition, installing profiles in the cluster, removing unused profiles from the cluster, binding a profile to container images, and audit log enrichment are all supported for seccomp, SELinux and AppArmor. Audit log recording and eBPF recording differ by type, and in-pod activity JSON log enrichment is a seccomp only feature. ### How do I install the Security Profiles Operator? There are four methods. The release manifest applied with kubectl, a Helm chart attached to each release, the operator lifecycle manager from operatorhub.io or the upstream catalog, and OpenShift through OperatorHub. On OpenShift cert-manager is not needed, and elsewhere you install cert-manager first and wait for its deployment to become available. ### Why does installing the Security Profiles Operator require cert-manager? The operator needs a certificate for its webhook and for its communication with the node daemon, which is the usual reason a Kubernetes operator pulls in cert-manager. The quick start applies the cert-manager release manifest and then waits for the deployment in its namespace to report the available condition. ### How does the Security Profiles Operator handle image provenance? The released images are published under a registry path with a separate document on verifying the released artifacts, and the Go dependencies include the sigstore signing and transparency log libraries together with an attestation library and the container registry client. The build image in the Dockerfile is pinned by digest rather than by tag, so the toolchain that compiles a released binary cannot be swapped remotely, and the build configuration restricts Nix substitution to the public cache only. ## Sources - [Issues](https://github.com/kubernetes-sigs/security-profiles-operator/issues) - [kubernetes-sigs/security-profiles-operator on GitHub](https://github.com/kubernetes-sigs/security-profiles-operator) - [License: Apache-2.0](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/LICENSE) - [README](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/README.md) - [Releases](https://github.com/kubernetes-sigs/security-profiles-operator/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubernetes-sigs-security-profiles-operator