Seccomp and Kubernetes [page]deterministic
Seccomp stands for secure computing mode and has been a feature of the Linux kernel since version 2.6.12. It can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a [node](#gloss:node) to your Pods and containers.
## Seccomp fields
There are four ways to specify a seccomp profile for a [pod](#gloss:pod):
- for the whole Pod using [`spec.securityContext.seccompProfile`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)
- for a single container using [`spec.containers[*].securityContext.seccompProfile`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)
- for an (restartable / sidecar) init container using [`spec.initContainers[*].securityContext.seccompProfile`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)
- for an [ephemeral container](/docs/concepts/workloads/pods/ephemeral-containers) using [`spec.ephemeralContainers[*].securityContext.seccompProfile`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-2)
The Pod in the example above runs as `Unconfined`, while the `ephemeral-container` and `init-container` specifically defines `RuntimeDefault`. If the ephemeral or init container would not have set the `securityContext.seccompProfile` field explicitly, then the value would be inherited from the Pod. The same applies to the container, which runs a `Localhost` profile `my-profile.json`.
Generally speaking, fields from (ephemeral) containers have a higher priority than the Pod level value, while containers which do not set the seccomp field inherit the profile from the Pod.
> Note: It is not possible to apply a seccomp profile to a Pod or container running with `privileged: true` set in the container's `securityContext`. Privileged containers always run as `Unconfined`.
The following values are possible for the `seccompProfile.type`:
`Unconfined` : The workload runs without any seccomp restrictions.
`RuntimeDefault` : A default seccomp profile defined by the [container runtime](#gloss:container-runtime) is applied. The default profiles aim to provide a strong set of security defaults while preserving the functionality of the workload. It is possible that the default profiles differ between container runtimes and their release versions, for example when comparing those from [CRI-O](#gloss:cri-o) and [containerd](#gloss:containerd).
`Localhost` : The `localhostProfile` will be applied, which has to be available on the node disk (on Linux it's `/var/lib/kubelet/seccomp`). The availability of the seccomp profile is verified by the [container runtime](#gloss:container-runtime) on container creation. If the profile does not exist, then the container creation will fail with a `CreateContainerError`.
### `Localhost` profiles
Seccomp profiles are JSON files following the scheme defined by the [OCI runtime specification](https://github.com/opencontainers/runtime-spec/blob/f329913/config-linux.md#seccomp). A profile basically defines actions based on matched syscalls, but also allows to pass specific values as arguments to syscalls. For example:
```json { "defaultAction": "SCMP_ACT_ERRNO", "defaultErrnoRet": 38, "syscalls": [ { "names": [ "adjtimex", "alarm", "bind", "waitid", "waitpid", "write", "writev" ], "action": "SCMP_ACT_ALLOW" } ] } ```
The `defaultAction` in the profile above is defined as `SCMP_ACT_ERRNO` and will return as fallback to the actions defined in `syscalls`. The error is defined as code `38` via the `defaultErrnoRet` field.
The following actions are generally possible:
`SCMP_ACT_ERRNO` : Return the specified error code.
`SCMP_ACT_ALLOW` : Allow the syscall to be executed.
`SCMP_ACT_KILL_PROCESS` : Kill the process.
`SCMP_ACT_KILL_THREAD` and `SCMP_ACT_K …(trimmed)