Skip to content

Commit 603e3d0

Browse files
authored
Merge pull request #41948 from mrgiles/40855_sec_checklist_seccomp_status
Reword seccomp paragraph to remove alpha feature reference
2 parents 371fdc7 + 3581bb0 commit 603e3d0

File tree

1 file changed

+15
-17
lines changed

1 file changed

+15
-17
lines changed

content/en/docs/concepts/security/security-checklist.md

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -97,6 +97,7 @@ For restricted LoadBalancer and ExternalIPs use, see
9797
[CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs](https://github.com/kubernetes/kubernetes/issues/97076)
9898
and the [DenyServiceExternalIPs admission controller](/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips)
9999
for further information.
100+
100101
## Pod security
101102

102103
- [ ] RBAC rights to `create`, `update`, `patch`, `delete` workloads is only granted if necessary.
@@ -153,23 +154,20 @@ Memory limit superior to request can expose the whole node to OOM issues.
153154

154155
### Enabling Seccomp
155156

156-
Seccomp can improve the security of your workloads by reducing the Linux kernel
157-
syscall attack surface available inside containers. The seccomp filter mode
158-
leverages BPF to create an allow or deny list of specific syscalls, named
159-
profiles. Those seccomp profiles can be enabled on individual workloads,
160-
[a security tutorial is available](/docs/tutorials/security/seccomp/). In
161-
addition, the [Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator)
162-
is a project to facilitate the management and use of seccomp in clusters.
163-
164-
For historical context, please note that Docker has been using
165-
[a default seccomp profile](https://docs.docker.com/engine/security/seccomp/)
166-
to only allow a restricted set of syscalls since 2016 from
167-
[Docker Engine 1.10](https://www.docker.com/blog/docker-engine-1-10-security/),
168-
but Kubernetes is still not confining workloads by default. The default seccomp
169-
profile can be found [in containerd](https://github.com/containerd/containerd/blob/main/contrib/seccomp/seccomp_default.go)
170-
as well. Fortunately, [Seccomp Default](/blog/2021/08/25/seccomp-default/), a
171-
new alpha feature to use a default seccomp profile for all workloads can now be
172-
enabled and tested.
157+
Seccomp stands for secure computing mode and has been a feature of the Linux kernel since version 2.6.12.
158+
It can be used to sandbox the privileges of a process, restricting the calls it is able to make
159+
from userspace into the kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto
160+
a node to your Pods and containers.
161+
162+
Seccomp can improve the security of your workloads by reducing the Linux kernel syscall attack
163+
surface available inside containers. The seccomp filter mode leverages BPF to create an allow or
164+
deny list of specific syscalls, named profiles.
165+
166+
Since Kubernetes 1.27, you can enable the use of `RuntimeDefault` as the default seccomp profile
167+
for all workloads. A [security tutorial](/docs/tutorials/security/seccomp/) is available on this
168+
topic. In addition, the
169+
[Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator)
170+
is a project that facilitates the management and use of seccomp in clusters.
173171

174172
{{< note >}}
175173
Seccomp is only available on Linux nodes.

0 commit comments

Comments
 (0)