Detections
Analytics

4.6.2 Require RuntimeDefault seccomp or approved custom profiles for workload pods

Information

Require GKE workload pods to use the RuntimeDefault seccomp profile unless an approved custom Localhost profile is required. Seccomp should be configured in the pod or container security context to reduce the system calls available to containers.

Seccomp limits the Linux system calls that a container can make, reducing the kernel attack surface available to a compromised workload. In GKE clusters, seccomp profiles must be applied manually because GKE does not apply a profile for you. Using RuntimeDefault applies the container runtime's default seccomp profile, while approved Localhost profiles can be used when workloads require more specific syscall controls.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Update the workload controller templates for any Pods returned by the audit so seccomp is defined in the source manifest, not patched directly on running Pods. Apply the setting through the owning Deployment, StatefulSet, DaemonSet, Job, CronJob, Helm chart, Kustomize overlay, or GitOps source.

 -

Set securityContext.seccompProfile.type to RuntimeDefault at the Pod level where possible so all containers inherit the runtime default seccomp profile.

 -

Use container level seccomp settings only when a specific container requires a different approved profile than the rest of the Pod.

 -

Replace Unconfined with RuntimeDefault unless there is a documented and approved exception.

 -

Allow Localhost only for approved custom seccomp profiles, and confirm the profile is documented, tested, and available on every node where the workload can run.

 -

Redeploy the workload and rerun the audit to confirm no unset or Unconfined findings remain.

After remediation, update workload deployment standards so new manifests explicitly define RuntimeDefault or an approved custom seccomp profile before release.

Impact:

Workloads that require blocked system calls might fail or behave differently when RuntimeDefault is enforced. If RuntimeDefault is too restrictive or not restrictive enough, teams must test and manage approved custom Localhost profiles for Standard clusters, including distributing profile files to the appropriate nodes and validating workload compatibility before production rollout.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, 800-53|CM-7, CSCv7|5.2

Plugin: GCP

Control ID: 58653d3de97963d659c9bf949332a80cada809363e5ed825c5969ed18fd5cc37