> ## 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 IPC Namespace ### More Info: Sharing the host IPC namespace allows a container to access shared memory of other processes on the node. Enforce policies that restrict admission of hostIPC containers. ### Risk Level High ### Address Security ### Compliance Standards * CIS OKE ### Triage and Remediation ### Remediation 1. **List existing pods using hostIPC in all namespaces** * Run on: any machine with kubectl access * Command: ```bash theme={null} kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' --no-headers | grep -w true || echo "No pods with hostIPC: true found" ``` * Review which workloads currently require `hostIPC: true`, and document the business/technical justification for each. 2. **Inspect pod specs that use hostIPC to understand why it is needed** * Run on: any machine with kubectl access * For each namespace with `hostIPC: true` pods: ```bash theme={null} NAMESPACE= kubectl get pods -n "$NAMESPACE" -o yaml | awk '/^ hostIPC: true/{show=1} show{print} /^status:/{show=0}' ``` * Decide case-by-case whether the host IPC access is strictly required or can be removed/alternative design used. 3. **Review existing admission controls (e.g. Pod Security Standards / policies) per namespace** * Run on: any machine with kubectl access * If using built-in Pod Security admission labels: ```bash theme={null} kubectl get ns --show-labels ``` * If using Gatekeeper/Kyverno or another policy engine, list policies and identify those that constrain `spec.hostIPC`: ```bash theme={null} # Gatekeeper example kubectl get k8spsp* constraints.constraints.gatekeeper.sh -A 2>/dev/null || true kubectl get constraints.constraints.gatekeeper.sh -A 2>/dev/null || true # Kyverno example kubectl get clusterpolicy,policy -A 2>/dev/null || true ``` * Determine which namespaces hosting user workloads currently lack any policy preventing `hostIPC: true`. 4. **Decide and design namespace-level policy to minimize hostIPC** * For each user-workload namespace, decide: * Should `hostIPC` be completely forbidden? * Are there exceptional workloads that must be allowed, and how will they be identified (labels, dedicated namespace, etc.)? * Based on your admission controller (Pod Security, Gatekeeper, Kyverno, etc.), design or select a policy that: * Denies pods with `spec.hostIPC: true` in general user namespaces. * Optionally allows only explicitly approved workloads/namespaces. 5. **Apply or adjust the policy manifests for each user-workload namespace** * Run on: any machine with kubectl access * Apply your chosen policy manifests using `kubectl apply -f .yaml` (content depends on your chosen policy engine and your decision in step 4). * For namespaces that must permit hostIPC for specific workloads, document and implement a controlled exception mechanism (e.g., dedicated namespace with stricter access control). 6. **Re-verify that hostIPC usage is minimized and new admission is restricted** * Run on: any machine with kubectl access * Confirm no unintended pods use hostIPC: ```bash theme={null} kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' --no-headers | grep -w true || echo "No pods with hostIPC: true found (except any intentional exceptions)" ``` * Attempt (in a test namespace) to create a pod with `hostIPC: true` and confirm it is rejected by the policy, adjusting the policy if necessary. ### Using kubectl Run all commands from any machine with `kubectl` access. #### 1. Discover current PodSecurity admission level per namespace These labels indicate if baseline/restricted Pod Security is enforced, which can block `hostIPC: true`. ```sh theme={null} kubectl get ns --show-labels ``` Potential problem: * Namespaces that run user workloads and either: * Have no `pod-security.kubernetes.io/*` labels, or * Are labeled with `privileged` or have only `warn`/`audit` levels, not `enforce`, may allow `hostIPC: true` pods. Focus on namespaces like `default`, app-specific namespaces, and any non-system namespaces. #### 2. List existing pods/containers using hostIPC ```sh theme={null} kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' ``` Any output indicates pods that are sharing the host IPC namespace and should be reviewed. To inspect one of them: ```sh theme={null} kubectl get pod -n -o yaml ``` Look for: ```yaml theme={null} spec: hostIPC: true ``` Problem indication: * Any workload pod (not a deliberately privileged/system tool) with `hostIPC: true` is a potential security concern. #### 3. Check workloads that could create hostIPC pods Deployments: ```sh theme={null} kubectl get deploy -A kubectl get deploy -A -o yaml | grep -n "hostIPC" ``` DaemonSets: ```sh theme={null} kubectl get daemonset -A kubectl get daemonset -A -o yaml | grep -n "hostIPC" ``` StatefulSets: ```sh theme={null} kubectl get statefulset -A kubectl get statefulset -A -o yaml | grep -n "hostIPC" ``` Problem indication: * Any controller spec containing `hostIPC: true` will continuously create pods with host IPC enabled unless changed. #### 4. Find admission policies that address hostIPC (if using Kyverno/OPA/Gatekeeper, etc.) Kyverno ClusterPolicies: ```sh theme={null} kubectl get clusterpolicy | sed '1d' || echo "No Kyverno ClusterPolicies found" ``` If present, inspect for hostIPC rules: ```sh theme={null} kubectl get clusterpolicy -o yaml | grep -n "hostIPC" ``` Gatekeeper constraints (if installed): ```sh theme={null} kubectl get constrainttemplates || echo "No Gatekeeper ConstraintTemplates found" kubectl get constraints --all-namespaces || echo "No Gatekeeper constraints found" kubectl get constraints --all-namespaces -o yaml | grep -n "hostIPC" ``` Problem indication: * No admission policies referencing `hostIPC` in namespaces with user workloads means there is no explicit control preventing `hostIPC: true` pods. #### 5. Verification after any policy decisions After you adjust labels/policies manually, verify again: ```sh theme={null} # 1) Confirm no new hostIPC pods exist kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' # 2) Confirm namespaces have intended PodSecurity labels kubectl get ns --show-labels # 3) Confirm admission policies reference hostIPC as intended (if used) kubectl get clusterpolicy -o yaml | grep -n "hostIPC" || true kubectl get constraints --all-namespaces -o yaml | grep -n "hostIPC" || true ``` Any remaining `hostIPC: true` workloads should be individually reviewed to decide if they are truly necessary and appropriately isolated. ```bash theme={null} #!/usr/bin/env bash # Report pods that share the host IPC namespace, cluster-wide. # Run on: any machine with kubectl access and current kube-context set. set -euo pipefail echo "=== Host IPC usage by pods (hostIPC: true) ===" echo # 1) List all pods with hostIPC: true, across all namespaces kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' \ | sort \ | awk 'BEGIN { printf "%-30s %-40s %-30s\n", "NAMESPACE", "POD", "SERVICEACCOUNT"; print "------------------------------ ---------------------------------------- ------------------------------" } { printf "%-30s %-40s %-30s\n", $1, $2, $3 }' echo echo "=== Namespaces that contain pods with hostIPC: true ===" kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' \ | sort -u echo echo "=== Detailed spec for each hostIPC pod (for review) ===" for ns in $(kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' | sort -u); do echo echo "Namespace: ${ns}" echo "-----------------------------" # Show only the hostIPC=true field and basic identifiers to keep it readable kubectl get pods -n "${ns}" \ -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}POD: {.metadata.name} SA: {.spec.serviceAccountName} hostIPC: {.spec.hostIPC}{"\n"}{end}' done echo echo "=== OPTIONAL: PodSecurity-related labels on each affected namespace ===" echo "(These labels influence whether hostIPC is allowed under Pod Security Admission)" echo for ns in $(kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.namespace}{"\n"}{end}' | sort -u); do echo "Namespace: ${ns}" kubectl get ns "${ns}" --show-labels echo done ``` **How to interpret the output** * The **first table** lists all pods that currently have `hostIPC: true`. * Any entry here is a **potential problem** that must be explicitly justified as an exception. * The **“Namespaces that contain pods with hostIPC: true”** list shows where you must ensure admission policies (e.g., Pod Security, PSP replacements, or validating admission policies) are configured to control or forbid `hostIPC`. * The **detailed spec** section helps you review: * Which service accounts and applications are using host IPC. * Whether usage aligns with an approved exception. * The **namespace labels** section helps you see if Pod Security (or equivalent) is configured strongly enough; namespaces with permissive labels while also having `hostIPC: true` pods are higher-risk and should be reviewed closely. This script only reports; you must decide case by case whether each `hostIPC: true` pod is acceptable and then adjust admission policies and workload manifests accordingly.