Review seccomp profile settings

Description

Seccomp restricts the system calls a container can use. Without an effective profile, or with Unconfined, the container may have access to a broader set of system calls.

Consider securityContext.seccompProfile.type: RuntimeDefault for ordinary workloads. Check Pod settings, container overrides and node defaults together. With SeccompDefault enabled on the node, omission can still apply the runtime default.

Potential impact

• More system calls may be available for abuse after a container compromise.
• Runtime isolation may be weaker.
• Inconsistent workload profiles can make security controls harder to manage.

Remediation

• Specify RuntimeDefault in Pod or container securityContext.seccompProfile and verify the actual profile.
• For special requirements, provide a reviewed Localhost profile on the relevant nodes and test normal operation.
• Use the current field instead of old annotations. Privileged containers bypass seccomp restrictions, so remove unnecessary privileged access separately.

Examples

The annotation key in the first example is not a supported seccomp setting. The image name is illustrative; use the actual application image and test profile compatibility.

Before

apiVersion: v1
kind: Pod
metadata:
  name: pod-test-3
  annotations:
    seccomp.security.alpha.kubernetes.io/defaultProfileName: "rntim/dfl"
spec:
  containers:
    - name: foobar
      image: foo/bar:latest

After

apiVersion: v1
kind: Pod
metadata:
  name: pod-test-1
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: foobar
      image: foo/bar:latest

Explanation:

• Before: The unsupported annotation key and misspelled value do not apply the intended profile. Check the effective profile and node defaults.
• After: The current Pod securityContext field selects the runtime default profile. Check that container settings do not override it.

References

• CWE-665
• Kubernetes documentation