Skip to main content

More Info:

Apply Security Context to Your Pods and Containers

Risk Level

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. List pods and identify those missing securityContext
    • Run on: any machine with kubectl access
    • This lists pods with no pod-level or container-level securityContext defined.
  2. Inspect security context details for a specific pod
    • Run on: any machine with kubectl access
    • Review which settings (runAsUser, runAsNonRoot, readOnlyRootFilesystem, capabilities, privileged, hostNetwork, hostPID, hostIPC, seccompProfile, etc.) are missing or overly permissive.
  3. Review workload owners (Deployments, etc.) for missing or weak security contexts
    • Run on: any machine with kubectl access
    • Identify templates that lack securityContext or set privileged: true, allow privilege escalation, broad capabilities, or host namespaces/paths.
  4. Decide required security context based on app needs and org policy
    • For each workload identified in steps 1–3, review with the app owner whether it can:
      • Run as non-root (runAsNonRoot: true, runAsUser: non-0 UID, runAsGroup)
      • Use a read-only root filesystem
      • Drop all capabilities and add back only specific required ones
      • Avoid privileged: true and avoid hostPath, hostNetwork, hostPID, hostIPC where possible
    • Refer to your org’s baseline and the CIS Google Container-Optimized OS Benchmark to choose appropriate defaults.
  5. Update manifests to add or tighten securityContext
    • Run on: any machine with kubectl access
    • Export current manifest, edit locally, then apply:
    • In /tmp/"$WORKLOAD".yaml, under .spec.template.spec add or adjust, for example:
    • Then apply:
  6. Re-verify that pods now have appropriate security contexts
    • Run on: any machine with kubectl access
    • Confirm that critical workloads are no longer listed, and spot-check updated pods with:
Problem indication:
  • POD_SC is <none> for most pods, and
  • CONTAINERS_SC is <none> or {} (empty) for most containers.
    This shows security context is largely not defined.

In the output, focus on:
  • .spec.securityContext (pod-level)
  • .spec.containers[*].securityContext
  • .spec.initContainers[*].securityContext (if present)
Problem indication:
  • Missing securityContext blocks entirely.
  • Present but empty securityContext {} with no meaningful fields.
  • Risky settings, for example:
    • runAsUser: 0 or runAsNonRoot: false
    • privileged: true
    • allowPrivilegeEscalation: true
    • Broad capabilities.add (e.g., SYS_ADMIN, NET_ADMIN).

Problem indication (requires human review):
  • runAsUser= is empty and runAsNonRoot= is empty/false (likely root).
  • privileged=true or allowPrivilegeEscalation=true without a strong justification.

Problem indication:
  • Any application or multi-tenant workload appears in this list without a clear, documented need to be privileged.

Problem indication:
  • Application pods listed here generally need stricter securityContext (e.g., allowPrivilegeEscalation: false) unless there is a specific requirement.

These commands only surface current state. A human must decide, per workload, which security context fields to add or tighten based on application needs and your organization’s security policy.

Additional Reading: