> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Minimize The Admission Privileged Containers ### 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 1. **List all pods using privileged containers (evidence gathering)** * Run on: any machine with kubectl access ```bash theme={null} kubectl get pods --all-namespaces -o json \ | jq -r '.items[] | select( (.spec.containers[]? | select(.securityContext.privileged == true)) or (.spec.initContainers[]? | select(.securityContext.privileged == true)) ) | [.metadata.namespace, .metadata.name] | @tsv' ``` 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: ```bash theme={null} kubectl get ns --show-labels ``` b) If using Pod Security Policies (legacy) in this cluster, list them and inspect the `privileged` field and related rules: ```bash theme={null} kubectl get psp -o yaml ``` 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: ```bash theme={null} kubectl -n get pod -o yaml ``` 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: ```yaml theme={null} securityContext: privileged: false ``` c) Apply the updated manifest: ```bash theme={null} kubectl apply -f .yaml ``` 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: ```bash theme={null} kubectl label namespace \ pod-security.kubernetes.io/enforce=restricted \ --overwrite ``` * 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: ```bash theme={null} kubectl get pods --all-namespaces -o json \ | jq -r '.items[] | select( (.spec.containers[]? | select(.securityContext.privileged == true)) or (.spec.initContainers[]? | select(.securityContext.privileged == true)) ) | [.metadata.namespace, .metadata.name] | @tsv' ``` 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. ```bash theme={null} # 1) List all namespaces # Run on: any machine with kubectl access kubectl get namespaces ``` 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). ```bash theme={null} # 2) Find pods that request privileged containers (current state) # Run on: any machine with kubectl access kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" ") {.metadata.name}{"\t"}{range .spec.containers[*]}{.name}{"="} {.securityContext.privileged}{"; "}{end}{"\n"}{end}' | grep "=true" ``` **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. ```bash theme={null} # 3) Inspect full pod spec for a specific result from step 2 # Replace and from the previous output kubectl get pod -n -o yaml ``` 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. ```bash theme={null} # 4) Find workloads that can create privileged containers via templates # (Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs) kubectl get deploy,sts,ds,rs,job,cronjob --all-namespaces -o json | \ jq -r ' .items[] | .kind as $k | .metadata.namespace as $ns | .metadata.name as $n | ((.spec.template.spec.containers // []) + (.spec.template.spec.initContainers // []))[]? | select(.securityContext.privileged == true) | "\($k)\t\($ns)\t\($n)\t" + (.name + "=privileged=true") ' ``` **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. ```bash theme={null} # 5) Check for default PodSecurity admission behavior that might allow privileged pods # (GKE uses PodSecurity Admission by default in recent versions) kubectl get ns -o json | \ jq -r ' .items[] | .metadata.name as $ns | (.metadata.labels["pod-security.kubernetes.io/enforce"] // "none") as $enforce | (.metadata.labels["pod-security.kubernetes.io/audit"] // "none") as $audit | (.metadata.labels["pod-security.kubernetes.io/warn"] // "none") as $warn | "\($ns)\tenforce=\($enforce)\taudit=\($audit)\twarn=\($warn)" ' ``` **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. ```bash theme={null} # 6) (If PSPs are still enabled in your cluster) list any PodSecurityPolicies kubectl get podsecuritypolicies.policy -o yaml ``` 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" -n **Problem 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:`) should be carefully reviewed. ```bash theme={null} #!/usr/bin/env bash # Run on: any machine with kubectl access # Purpose: Report where privileged pods/containers are allowed or in use set -euo pipefail echo "== 1. Namespaces with any privileged pods (current workload state) ==" kubectl get pods --all-namespaces -o json \ | jq -r ' .items[] | . as $pod | ($pod.spec.containers + ($pod.spec.initContainers // []))[] | select(.securityContext.privileged == true) | "\($pod.metadata.namespace)\t\($pod.metadata.name)\t\(.name)\tPRIVILEGED=true" ' 2>/dev/null | sort || echo "jq not installed or no privileged containers found." echo echo "Explanation: Any line here shows a running pod with at least one container running privileged." echo "These should be reviewed; most workloads should not appear here." echo echo "== 2. Pods whose spec *requests* privileged containers (even if not running now) ==" kubectl get pods --all-namespaces -o json \ | jq -r ' .items[] | . as $pod | ($pod.spec.containers + ($pod.spec.initContainers // []))[] | select(.securityContext.privileged == true) | "\($pod.metadata.namespace)\t\($pod.metadata.name)\t\(.name)\tPRIVILEGED_REQUESTED=true" ' 2>/dev/null | sort || echo "jq not installed or no pods request privileged containers." echo echo "Explanation: Any line indicates a pod spec that explicitly sets securityContext.privileged: true." echo "These are candidates for redesign or exception documentation." echo echo "== 3. Namespaces that allow privileged pods via PodSecurity admission labels (v1.25+) ==" kubectl get ns --show-labels | awk ' NR==1 { print; next } /pod-security.kubernetes.io/ { print } ' echo echo "Explanation:" echo "- For clusters using Pod Security Admission, look at labels:" echo " pod-security.kubernetes.io/enforce" echo " pod-security.kubernetes.io/audit" echo " pod-security.kubernetes.io/warn" echo "- Namespaces labeled with \"privileged\" or a custom policy that permits privileged containers" echo " effectively allow privileged workloads. Those namespaces should be explicitly justified." echo echo "== 4. (If present) PodSecurityPolicy objects that allow privileged containers ==" if kubectl api-resources 2>/dev/null | grep -q "^podsecuritypolicies"; then kubectl get podsecuritypolicies.policy -o json \ | jq -r ' .items[] | select(.spec.privileged == true) | "\(.metadata.name)\tPRIVILEGED_ALLOWED=true" ' 2>/dev/null | sort || echo "jq not installed or no PSPs allow privileged=true." else echo "PodSecurityPolicy API not present in this cluster (likely removed in v1.25+)." fi echo echo "Explanation: Any PSP listed here has spec.privileged: true and allows privileged pods." echo "Review which namespaces/service accounts can use these PSPs (RBAC bindings) and justify or tighten." echo echo "== How to interpret problematic output ==" echo "- Any non-empty output in sections 1 or 2 indicates pods/containers explicitly running or requesting" echo " privileged=true. Each should be reviewed; only tightly controlled infrastructure components" echo " should need this." echo "- Namespaces in section 3 with pod-security.* labels set to \"privileged\" (or equivalent) allow" echo " privileged workloads; they should be minimized and well-documented." echo "- Any PSP listed in section 4 indicates a cluster-wide policy object that permits privileged pods." echo " Its usage and scope 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: * [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)