You are viewing documentation for Kubernetes version: v1.24
Kubernetes v1.24 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
What's new in Security Profiles Operator v0.4.0
Authors: Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert
The Security Profiles Operator (SPO) is an out-of-tree Kubernetes enhancement to make the management of seccomp, SELinux and AppArmor profiles easier and more convenient. We're happy to announce that we recently released v0.4.0 of the operator, which contains a ton of new features, fixes and usability improvements.
It has been a while since the last v0.3.0 release of the operator. We added new features, fine-tuned existing ones and reworked our documentation in 290 commits over the past half year.
One of the highlights is that we're now able to record seccomp and SELinux
profiles using the operators log enricher.
This allows us to reduce the dependencies required for profile recording to have
syslog (as fallback) running on the
nodes. All profile recordings in the operator work in the same way by using the
ProfileRecording CRD as well as their corresponding label
selectors. The log
enricher itself can be also used to gather meaningful insights about seccomp and
SELinux messages of a node. Checkout the official
to learn more about it.
seccomp related improvements
Beside the log enricher based recording we now offer an alternative to record
seccomp profiles by utilizing ebpf. This optional feature can
be enabled by setting
true. This results in running a
dedicated container, which ships a custom bpf module on every node to collect
the syscalls for containers. It even supports older Kernel versions which do not
expose the BPF Type Format (BTF) per
default as well as the
arm64 architectures. Checkout
to see it in action. By the way, we now add the seccomp profile architecture of
the recorder host to the recorded profile as well.
We also graduated the seccomp profile API from
aligns with our overall goal to stabilize the CRD APIs over time. The only thing
which has changed is that the seccomp profile type
Architectures now points to
Arch instead of
Managing SELinux policies (an equivalent to using
you would normally call on a single server) is not done by SPO
itself, but by another container called selinuxd to provide better
isolation. This release switched to using selinuxd containers from
a personal repository to images located under our team's quay.io
The selinuxd repository has moved as well to the containers GitHub
Please note that selinuxd links dynamically to
libsemanage and mounts the
SELinux directories from the nodes, which means that the selinuxd container
must be running the same distribution as the cluster nodes. SPO defaults
to using CentOS-8 based containers, but we also build Fedora based ones.
If you are using another distribution and would like us to add support for
it, please file an issue against selinuxd.
This release adds support for recording of SELinux profiles.
The recording itself is managed via an instance of a
Resource as seen in an
in our repository. From the user's point of view it works pretty much the same
as recording of seccomp profiles.
Under the hood, to know what the workload is doing SPO installs a special
permissive policy called selinuxrecording
on startup which allows everything and logs all AVCs to
These AVC messages are scraped by the log enricher component and when
the recorded workload exits, the policy is created.
SELinuxProfile CRD graduation
v1alpha2 version of the
SelinuxProfile object has been introduced. This
removes the raw Common Intermediate Language (CIL) from the object itself and
instead adds a simple policy language to ease the writing and parsing
RawSelinuxProfile object was also introduced. This contains a
wrapped and raw representation of the policy. This was intended for folks to be
able to take their existing policies into use as soon as possible. However, on
validations are done here.
This version introduces the initial support for AppArmor, allowing users to load and unload AppArmor profiles into cluster nodes by using the new AppArmorProfile CRD.
The operator now exposes metrics, which are described in detail in
our new metrics documentation.
We decided to secure the metrics retrieval process by using
kube-rbac-proxy, while we ship an
spo-metrics-client cluster role (and binding) to retrieve the
metrics from within the cluster. If you're using
then we provide an out of the box working
to access the metrics.
Debuggability and robustness
Beside all those new features, we decided to restructure parts of the Security
Profiles Operator internally to make it better to debug and more robust. For
example, we now maintain an internal gRPC API to communicate
within the operator across different features. We also improved the performance
of the log enricher, which now caches results for faster retrieval of the log
data. The operator can be put into a more verbose log mode
We also print the used
libbpf versions on startup, as well as
expose CPU and memory profiling endpoints for each container via the
Dedicated liveness and startup probes inside of the operator daemon will now
additionally improve the life cycle of the operator.
Thank you for reading this update. We're looking forward to future enhancements of the operator and would love to get your feedback about the latest release. Feel free to reach out to us via the Kubernetes slack #security-profiles-operator for any feedback or question.