Skip to content

Commit 78b252f

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #30689 from saschagrunert/spo-release
Add blog post about SPO v0.4.0 release
2 parents e2e7843 + 7979bad commit 78b252f

File tree

1 file changed

+148
-0
lines changed
  • content/en/blog/_posts/2021-12-17-security-profiles-operator-v0.4.0

1 file changed

+148
-0
lines changed

‎content/en/blog/_posts/2021-12-17-security-profiles-operator-v0.4.0/index.md

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
---
2+
layout: blog
3+
title: "What's new in Security Profiles Operator v0.4.0"
4+
date: 2021-12-17
5+
slug: security-profiles-operator
6+
---
7+
8+
**Authors:** Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert
9+
10+
---
11+
12+
The [Security Profiles Operator (SPO)](https://sigs.k8s.io/security-profiles-operator)
13+
is an out-of-tree Kubernetes enhancement to make the management of
14+
[seccomp](https://en.wikipedia.org/wiki/Seccomp),
15+
[SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) and
16+
[AppArmor](https://en.wikipedia.org/wiki/AppArmor) profiles easier and more
17+
convenient. We're happy to announce that we recently [released
18+
v0.4.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.4.0)
19+
of the operator, which contains a ton of new features, fixes and usability
20+
improvements.
21+
22+
## What's new
23+
24+
It has been a while since the last
25+
[v0.3.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.3.0)
26+
release of the operator. We added new features, fine-tuned existing ones and
27+
reworked our documentation in 290 commits over the past half year.
28+
29+
One of the highlights is that we're now able to record seccomp and SELinux
30+
profiles using the operators [log enricher](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#log-enricher-based-recording).
31+
This allows us to reduce the dependencies required for profile recording to have
32+
[auditd](https://linux.die.net/man/8/auditd) or
33+
[syslog](https://en.wikipedia.org/wiki/Syslog) (as fallback) running on the
34+
nodes. All profile recordings in the operator work in the same way by using the
35+
`ProfileRecording` CRD as well as their corresponding [label
36+
selectors](/docs/concepts/overview/working-with-objects/labels). The log
37+
enricher itself can be also used to gather meaningful insights about seccomp and
38+
SELinux messages of a node. Checkout the [official
39+
documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-the-log-enricher)
40+
to learn more about it.
41+
42+
### seccomp related improvements
43+
44+
Beside the log enricher based recording we now offer an alternative to record
45+
seccomp profiles by utilizing [ebpf](https://ebpf.io). This optional feature can
46+
be enabled by setting `enableBpfRecorder` to `true`. This results in running a
47+
dedicated container, which ships a custom bpf module on every node to collect
48+
the syscalls for containers. It even supports older Kernel versions which do not
49+
expose the [BPF Type Format (BTF)](https://www.kernel.org/doc/html/latest/bpf/btf.html) per
50+
default as well as the `amd64` and `arm64` architectures. Checkout
51+
[our documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#ebpf-based-recording)
52+
to see it in action. By the way, we now add the seccomp profile architecture of
53+
the recorder host to the recorded profile as well.
54+
55+
We also graduated the seccomp profile API from `v1alpha1` to `v1beta1`. This
56+
aligns with our overall goal to stabilize the CRD APIs over time. The only thing
57+
which has changed is that the seccomp profile type `Architectures` now points to
58+
`[]Arch` instead of `[]*Arch`.
59+
60+
### SELinux enhancements
61+
62+
Managing SELinux policies (an equivalent to using `semodule` that
63+
you would normally call on a single server) is not done by SPO
64+
itself, but by another container called selinuxd to provide better
65+
isolation. This release switched to using selinuxd containers from
66+
a personal repository to images located under [our team's quay.io
67+
repository](https://quay.io/organization/security-profiles-operator).
68+
The selinuxd repository has moved as well to [the containers GitHub
69+
organization](https://github.com/containers/selinuxd).
70+
71+
Please note that selinuxd links dynamically to `libsemanage` and mounts the
72+
SELinux directories from the nodes, which means that the selinuxd container
73+
must be running the same distribution as the cluster nodes. SPO defaults
74+
to using CentOS-8 based containers, but we also build Fedora based ones.
75+
If you are using another distribution and would like us to add support for
76+
it, please file [an issue against selinuxd](https://github.com/containers/selinuxd/issues).
77+
78+
#### Profile Recording
79+
80+
This release adds support for recording of SELinux profiles.
81+
The recording itself is managed via an instance of a `ProfileRecording` Custom
82+
Resource as seen in an
83+
[example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/profilerecording-selinux-logs.yaml)
84+
in our repository. From the user's point of view it works pretty much the same
85+
as recording of seccomp profiles.
86+
87+
Under the hood, to know what the workload is doing SPO installs a special
88+
permissive policy called [selinuxrecording](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/profiles/selinuxrecording.cil)
89+
on startup which allows everything and logs all AVCs to `audit.log`.
90+
These AVC messages are scraped by the log enricher component and when
91+
the recorded workload exits, the policy is created.
92+
93+
#### `SELinuxProfile` CRD graduation
94+
95+
An `v1alpha2` version of the `SelinuxProfile` object has been introduced. This
96+
removes the raw Common Intermediate Language (CIL) from the object itself and
97+
instead adds a simple policy language to ease the writing and parsing
98+
experience.
99+
100+
Alongside, a `RawSelinuxProfile` object was also introduced. This contains a
101+
wrapped and raw representation of the policy. This was intended for folks to be
102+
able to take their existing policies into use as soon as possible. However, on
103+
validations are done here.
104+
105+
### AppArmor support
106+
107+
This version introduces the initial support for AppArmor, allowing users to load and
108+
unload AppArmor profiles into cluster nodes by using the new [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/crds/apparmorprofile.yaml) CRD.
109+
110+
To enable AppArmor support use the [enableAppArmor feature gate](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/config.yaml#L10) switch of your SPO configuration.
111+
Then use our [apparmor example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/apparmorprofile.yaml) to deploy your first profile across your cluster.
112+
113+
### Metrics
114+
115+
The operator now exposes metrics, which are described in detail in
116+
our new [metrics documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-metrics).
117+
We decided to secure the metrics retrieval process by using
118+
[kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy), while we ship an
119+
additional `spo-metrics-client` cluster role (and binding) to retrieve the
120+
metrics from within the cluster. If you're using
121+
[OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift),
122+
then we provide an out of the box working
123+
[`ServiceMonitor`](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#automatic-servicemonitor-deployment)
124+
to access the metrics.
125+
126+
#### Debuggability and robustness
127+
128+
Beside all those new features, we decided to restructure parts of the Security
129+
Profiles Operator internally to make it better to debug and more robust. For
130+
example, we now maintain an internal [gRPC](https://grpc.io) API to communicate
131+
within the operator across different features. We also improved the performance
132+
of the log enricher, which now caches results for faster retrieval of the log
133+
data. The operator can be put into a more [verbose log mode](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#set-logging-verbosity)
134+
by setting `verbosity` from `0` to `1`.
135+
136+
We also print the used `libseccomp` and `libbpf` versions on startup, as well as
137+
expose CPU and memory profiling endpoints for each container via the
138+
[`enableProfiling` option](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#enable-cpu-and-memory-profiling).
139+
Dedicated liveness and startup probes inside of the operator daemon will now
140+
additionally improve the life cycle of the operator.
141+
142+
## Conclusion
143+
144+
Thank you for reading this update. We're looking forward to future enhancements
145+
of the operator and would love to get your feedback about the latest release.
146+
Feel free to reach out to us via the Kubernetes slack
147+
[#security-profiles-operator](https://kubernetes.slack.com/messages/security-profiles-operator)
148+
for any feedback or question.

0 commit comments

Comments
 (0)