Container runtime security policies (seccomp, AppArmor) are applied

Without seccomp or AppArmor profiles, containers can make any Linux system call — including ptrace, mount, kexec, and others that have no role in application logic but are used in known container escape exploits (NIST 800-53 CM-7, CIS Kubernetes 5.7.2/5.7.3). Seccomp RuntimeDefault blocks over 300 system calls not used by typical applications, reducing the kernel attack surface measurably. Unconfined profiles explicitly disable all restrictions and are categorically worse than the default — any container with Unconfined is actively regressing security below Kubernetes defaults.

Apply seccompProfile: RuntimeDefault to all containers that do not require custom syscall access. In your Deployment manifest:

spec:
  template:
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL

RuntimeDefault uses the container runtime's built-in seccomp policy (Docker/containerd both ship sensible defaults). For workloads with custom syscall requirements, generate a profile with docker run --security-opt seccomp=unconfined --cap-drop=ALL to observe actual syscall usage, then build a Localhost profile. For AppArmor, annotate pods with container.apparmor.security.beta.kubernetes.io/<container>: runtime/default.

• ID: infrastructure-hardening.monitoring-incident-response.runtime-security-policy

• Severity: low

• What to look for: Count all Pod and container definitions across Kubernetes manifests. For each, check whether a seccomp profile (securityContext.seccompProfile) or AppArmor annotation (container.apparmor.security.beta.kubernetes.io/...) is set. Count the total containers and how many have runtime security policies applied.

• Pass criteria: Every container in production manifests has at least 1 runtime security policy applied — either a seccomp profile (RuntimeDefault or custom Localhost profile) or an AppArmor annotation. Policies must restrict system calls to those necessary for the application. Report: "X of Y containers have seccomp/AppArmor profiles applied."

• Fail criteria: Any container lacks both seccomp and AppArmor profiles, or profiles are set to Unconfined which allows all system calls.

• Skip (N/A) when: The runtime does not support seccomp/AppArmor, or the project is not containerized.

• Detail on fail: Quote the Deployment and container. Example: "Deployment 'web' container 'app' does not specify a seccomp profile. All system calls are allowed." or "AppArmor is available on the cluster but not enforced on any pods in namespace 'production'"

• Remediation: Apply seccomp profiles:

  securityContext:
    seccompProfile:
      type: RuntimeDefault
  

  Or use a custom profile:

  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: my-profile.json
  

  For AppArmor:

  metadata:
    annotations:
      container.apparmor.security.beta.kubernetes.io/app: localhost/k8s-apparmor-example-deny-write