> ## 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 Admission Of Containers Sharing The Host Process ID Namespace ### More Info: Sharing the host PID namespace lets a container view and interact with all processes on the node. Enforce policies that restrict admission of hostPID containers. ### Risk Level High ### Address Security ### Compliance Standards * CIS OKE ### Triage and Remediation ### Remediation 1. **Identify all pods using `hostPID` in each workload namespace** * Run on: any machine with kubectl access * Command: ```bash theme={null} kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort ``` * Record which namespaces and applications currently use `hostPID`. 2. **Review whether `hostPID` usage is strictly necessary** * For each identified pod, inspect its spec and discuss with the owning team whether it truly requires host-level process visibility (e.g., specific debugging/monitoring daemons). * Command (example for one pod): ```bash theme={null} kubectl -n get pod -o yaml ``` * Decide: keep `hostPID` (documented justification and owner) or plan to remove it from the pod spec. 3. **Check for existing admission controls related to `hostPID`** * Run on: any machine with kubectl access * If you use PSP (legacy clusters): ```bash theme={null} kubectl get psp -o yaml | grep -nA5 -B5 hostPID || echo "No PSP hostPID config found" ``` * If you use Pod Security Admission labels: ```bash theme={null} kubectl get ns --show-labels | grep pod-security.kubernetes.io ``` * If you use other admission controllers (e.g., Kyverno, Gatekeeper), list their policies and search for `hostPID` in the policy repo or manifests used to deploy them. 4. **Decide and implement a namespace-level policy for future pods** * For each *user workload* namespace, decide on the stance: * **Disallow hostPID by default**, with explicit exceptions via separate namespaces or explicit policy overrides. * Example Kyverno policy manifest snippet (to be customized and applied if you use Kyverno): ```yaml theme={null} apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: disallow-hostpid spec: validationFailureAction: enforce rules: - name: disallow-hostpid match: resources: kinds: - Pod validate: message: "Use of hostPID is not allowed." pattern: spec: hostPID: "false" ``` * Apply with: ```bash theme={null} kubectl apply -f disallow-hostpid.yaml ``` * If you use a different admission mechanism, create/adjust an equivalent rule there. 5. **Refactor existing workloads that do not need `hostPID`** * For pods where `hostPID` is not strictly required, update their manifests (Deployments, StatefulSets, DaemonSets, etc.) to remove `hostPID: true` or explicitly set `hostPID: false`. * Example edit for a Deployment: ```bash theme={null} kubectl -n edit deploy ``` * In the opened manifest, remove or change: ```yaml theme={null} spec: template: spec: hostPID: true ``` to either omit `hostPID` or set it to `false`. * Save and allow the controller to roll out the updated pods. 6. **Verify that `hostPID` usage is minimized and blocked going forward** * Re-run the discovery command: ```bash theme={null} kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort ``` * Confirm that: * Only explicitly justified system/monitoring pods (if any) still use `hostPID`. * Attempting to create a new pod with `hostPID: true` in a protected namespace is rejected by your admission policy (test with a small test pod manifest and `kubectl apply -f`). ```bash theme={null} # 1) List all pod security policies (if PSPs are enabled) # Run on: any machine with kubectl access kubectl get psp # Inspect PSP definitions for hostPID allowance kubectl get psp -o yaml | grep -C5 hostPID ``` Problem indication: * `hostPID: true` in a PSP that is referenced by service accounts used for user workloads means those workloads are allowed to request host PID sharing. *** ```bash theme={null} # 2) List current namespaces, so you can identify user-workload namespaces # Run on: any machine with kubectl access kubectl get ns ``` Manually identify which namespaces contain user workloads (vs. system/control-plane). *** ```bash theme={null} # 3) For each user-workload namespace, list all pods and check for hostPID usage # Replace with the actual namespace name # Run on: any machine with kubectl access kubectl get pods -n -o wide # Show full pod specs and search for hostPID kubectl get pods -n -o yaml | grep -C3 hostPID ``` Problem indication: * Any pod spec with `hostPID: true` is using the host PID namespace and must be reviewed. * Frequent or unreviewed use of `hostPID: true` in user namespaces suggests insufficient admission control. *** ```bash theme={null} # 4) Check workload controllers (Deployments, DaemonSets, StatefulSets, Jobs, CronJobs) for hostPID # Run on: any machine with kubectl access # Deployments kubectl get deploy -A -o yaml | grep -C3 hostPID # DaemonSets kubectl get ds -A -o yaml | grep -C3 hostPID # StatefulSets kubectl get sts -A -o yaml | grep -C3 hostPID # Jobs kubectl get jobs -A -o yaml | grep -C3 hostPID # CronJobs (batch/v1) kubectl get cronjobs -A -o yaml | grep -C3 hostPID ``` Problem indication: * Any controller template containing `hostPID: true` will continuously recreate pods with host PID access, making it harder to enforce restrictions. *** ```bash theme={null} # 5) If using Pod Security Admission (PSA), check namespace labels # Run on: any machine with kubectl access kubectl get ns --show-labels ``` Problem indication: * User-workload namespaces labeled with `pod-security.kubernetes.io/enforce` set to a level that permits `hostPID: true` (e.g., not `restricted` in recent Kubernetes versions) mean host PID usage may not be blocked by default and relies solely on workload authors’ choices. *** ```bash theme={null} # 6) If using Gatekeeper/OPA or another admission controller, list constraints # Example for Gatekeeper (if installed) # Run on: any machine with kubectl access kubectl get constrainttemplates kubectl get constraints --all-namespaces kubectl get constraints --all-namespaces -o yaml | grep -C5 hostPID ``` Problem indication: * Absence of any constraint touching `hostPID`, or constraints scoped only to non–user namespaces, means there is no enforced policy to minimize host PID containers. *** Verification (after you design and apply your chosen policy): ```bash theme={null} # Re-check for any pods or controllers still requesting hostPID kubectl get pods -A -o yaml | grep -C3 hostPID || echo "No pods with hostPID found" kubectl get deploy,ds,sts,jobs,cronjobs -A -o yaml | grep -C3 hostPID || echo "No controllers with hostPID found" ``` ```bash theme={null} #!/usr/bin/env bash # Report Pods and controllers that request hostPID=true across the cluster. # Run on: any machine with kubectl access and appropriate RBAC. set -euo pipefail echo "=== Checking Pods with hostPID: true ===" kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}' \ | sort || true echo echo "=== Checking Deployments with hostPID: true ===" kubectl get deployments --all-namespaces -o jsonpath='{range .items[?(@.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Checking StatefulSets with hostPID: true ===" kubectl get statefulsets --all-namespaces -o jsonpath='{range .items[?(@.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Checking DaemonSets with hostPID: true ===" kubectl get daemonsets --all-namespaces -o jsonpath='{range .items[?(@.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Checking ReplicaSets with hostPID: true (may include controller-owned sets) ===" kubectl get replicasets --all-namespaces -o jsonpath='{range .items[?(@.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Checking CronJobs with hostPID: true ===" kubectl get cronjobs --all-namespaces -o jsonpath='{range .items[?(@.spec.jobTemplate.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Checking Jobs with hostPID: true ===" kubectl get jobs --all-namespaces -o jsonpath='{range .items[?(@.spec.template.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \ | sort || true echo echo "=== Summary ===" echo "Any non-empty list above indicates pods or workload controllers that request hostPID: true." echo "For each, review whether hostPID is strictly required and, if not, remove hostPID: true from the pod spec." ``` Explanation of output indicating a problem: * Any line printed under any of the sections (Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, CronJobs, Jobs) identifies a workload that is configured with `hostPID: true`. * Workloads in user application namespaces with `hostPID: true` are the primary concern for this control and should be reviewed; where not strictly necessary, they should be reconfigured to avoid sharing the host PID namespace and governed by admission policies that prevent such configurations.