Skip to main content

More Info:

Do not generally permit containers to be run with the securityContext.privileged flag set to true.

Risk Level

Critical

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 all pods using privileged containers (evidence gathering)
    • Run on: any machine with kubectl access
    Save the output as your initial inventory of privileged pods.
  2. Identify how privileged pods are being admitted (exemptions, policies, namespaces)
    • Run on: any machine with kubectl access
      a) Check Pod Security admission labels on each namespace:
    b) If using Pod Security Policies (legacy) in this cluster, list them and inspect the privileged field and related rules:
    Review which namespaces/service accounts are allowed to use PSPs that permit privileged: true (via RBAC use bindings).
  3. Classify privileged usage as required or unnecessary
    For each pod from step 1, review its purpose and image, and determine if securityContext.privileged: true is strictly required (e.g., node-level monitoring, CNI, storage, low‑level debugging) or if finer-grained capabilities / other mechanisms would suffice.
    • To inspect the full pod spec for a specific pod:
    Decide pod-by-pod whether to (a) keep privileged, (b) remove privileged, or (c) replace with narrower capabilities (e.g., capabilities.add).
  4. Remove or reduce privileged settings where not strictly needed
    • Run on: any machine with kubectl access (editing manifests in your Git/IaC system is strongly recommended; use kubectl edit only for temporary/urgent changes).
      For each workload determined unnecessary to be privileged:
      a) Locate and edit its Deployment/StatefulSet/DaemonSet/Job manifest.
      b) In each relevant container spec, either remove the privileged setting or set it to false:
    c) Apply the updated manifest:
    Note: Changing controller specs will recreate pods; plan for any resulting restarts or brief disruption.
  5. Tighten admission controls for future pods
    • If using Pod Security (recommended on GKE):
      • Set stricter labels (e.g., pod-security.kubernetes.io/enforce=restricted) on namespaces that should not allow privileged pods:
    • If still using Pod Security Policies and they’re enabled in this cluster, ensure the PSPs bound to general workloads omit .spec.privileged or set it to false, and restrict use of any PSP that allows privileged containers only to specific service accounts/namespaces that require it.
  6. Re-verify and document accepted exceptions
    • Run on: any machine with kubectl access
      Re-run the evidence command from step 1 to confirm only intentionally approved privileged workloads remain:
    For any remaining privileged pods, record: namespace, controller (Deployment/DaemonSet/etc.), business owner, and justification, and ensure their namespaces/policies are explicitly configured as controlled exceptions.
Review the list to understand scope; the following commands should typically focus on non‑system namespaces (exclude kube-system, kube-public, etc., unless you intentionally run workloads there).
Problem indication: Any line returned here shows a pod with at least one container running with securityContext.privileged=true. Each match requires human review to decide if it is strictly necessary.
Review under .spec.containers[].securityContext and .spec.initContainers[].securityContext:
  • privileged: true indicates a privileged container. Decide whether the privilege is justified; if not, the workload manifest must be changed and redeployed.
Problem indication: Any line printed identifies a controller whose pod template includes securityContext.privileged: true. These controllers will continue to create privileged pods until their manifests are changed.
Problem indication:
  • Namespaces with enforce=privileged (or with no enforce label, depending on your cluster defaults) may admit privileged pods.
  • Namespaces intended to be restricted should typically use enforce=baseline or restricted. Any more‑permissive configuration should be reviewed.
Review each PSP:
  • A PSP with .spec.privileged: true or missing .spec.privileged but effectively permitting privileged pods (depending on other fields and RBAC bindings) is a potential concern.
  • Validate which service accounts / users are bound to such PSPs with RBAC:
kubectl get clusterrole,role -A -o yaml | grep -n “podsecuritypolicies” -nProblem indication: Any PSP that allows privileged pods and is bound (via Role/ClusterRole + RoleBinding/ClusterRoleBinding) to general workloads or broad principals (e.g., system:serviceaccounts:<namespace>) should be carefully reviewed.
Problem indicators:
  • Lines in sections 1 or 2: pods/containers with PRIVILEGED=true / PRIVILEGED_REQUESTED=true.
  • Namespaces in section 3 with Pod Security labels set to privileged (or a custom policy allowing privileged).
  • PSPs in section 4 with PRIVILEGED_ALLOWED=true.
These findings require human review and policy decisions; they cannot be safely remediated in a fully automated way.

Additional Reading: