---
# System prepended metadata

title: Kubernetes seccomp profile defaults

---

# Kubernetes seccomp profile defaults

The main motivation behind this proposal is to enhance the default Kubernetes
workload security. It should also unify the default seccomp behavior, which
right now depends on the internal implementations of container runtimes like
CRI-O and containerd. Adding official documentation for a unified default
seccomp profile would also increase the visibility of the feature, while making
it easier to understand for Kubernetes users.

## Proposal
Introduce a feature gate that enables a seccomp for all workloads by default.
There are a few options for what should be the default seccomp profile.


### Make runtime/default the new default
Today, the runtimes already have their own defined defaults so this option
means choosing that profile is the default. 

### Define a new kubernetes/default

Kubernetes ships a default seccomp profile `kubernetes/default`, which is the
new default `SeccompProfile.type` value for the `PodSecurityContext` as well as
the `SecurityContext` for every container.

On startup of the kubelet, it will place the default seccomp profile in a
pre-defined path on the host machine. The container runtime has to verify the
existence of this profile and apply it to the container.

A possible starting point to defining this profile is to look at docker,
containerd and cri-o default profiles. 

The advantage of defining a `kubernetes/default`


### Allow admin to pick one of kubernetes/default, runtime/default or a self-defined profile


## Migration
There could be a tool that updates all the pods in a test cluster to add the
proposed default profile and then the user/admin could adjust profiles
for some pods or set to unconfined so after they move to this feature,
there are no unexpected breakages.




<!-- TODOs:
- version skew handling. Do we want to fallback to runtime/default if the
  kubelet is too old (the local profile does not exist)
-->
