> ## 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 Of Containers Sharing The Host IPC Namespace

### More Info:

Containers sharing the host IPC namespace can access inter-process communication of other host processes. Their admission should be restricted via Pod Security Admission policies.

### Risk Level

High

### Address

Security

### Compliance Standards

* CIS AKS

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify namespaces with user workloads**
           * Run on: any machine with kubectl access
           ```bash theme={null}
           kubectl get ns
           ```
           Decide which namespaces are user-facing (exclude system namespaces like `kube-system`, `kube-public`, `kube-node-lease`, and cloud-provider/system add-on namespaces).

        2. **Find existing pods that use `hostIPC: true`**
           * Run on: any machine with kubectl access
           ```bash theme={null}
           for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
             echo "Namespace: $ns"
             kubectl get pods -n "$ns" -o json | \
               jq -r '.items[] | select(.spec.hostIPC==true) | .metadata.name' || true
           done
           ```
           Review any listed pods with application owners and decide whether `hostIPC` is strictly required. If not, plan to remove it from their Pod/Deployment/StatefulSet manifests and redeploy.

        3. **Review current Pod Security labels on namespaces**
           * Run on: any machine with kubectl access
           ```bash theme={null}
           kubectl get ns --show-labels
           ```
           For each user namespace, check whether `pod-security.kubernetes.io/enforce` (or `pod-security.kubernetes.io/warn`) is present and what level it is set to (`privileged`, `baseline`, or `restricted`). Note that `restricted` disallows `hostIPC: true`.

        4. **Decide the appropriate policy level per namespace**
           * For each user namespace:
             * If **no workloads require** `hostIPC`, plan to enforce `restricted`.
             * If **some workloads temporarily require** `hostIPC`, consider `baseline` or an exception namespace for those workloads, and plan to migrate them off `hostIPC` where possible.
             * Document any justified exceptions, including owning team, purpose, and review date.

        5. **Apply or adjust namespace Pod Security labels**
           * Run on: any machine with kubectl access
           * To enforce `restricted` where `hostIPC` is not required:
             ```bash theme={null}
             kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
             ```
           * To add a warning-level policy (e.g., cluster-wide baseline warnings):
             ```bash theme={null}
             kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
             ```
           Replace `NAMESPACE` with each chosen user namespace. Coordinate with application owners before enforcing in production to avoid unexpected admission failures.

        6. **Verify the effect of the policy and current usage**
           * Confirm namespace labels:
             ```bash theme={null}
             kubectl get ns --show-labels
             ```
           * Attempt (in a test namespace) to create a pod with `hostIPC: true` and ensure it is rejected where `enforce=restricted` is set.
           * Re-run the `hostIPC` usage scan to confirm no unintended `hostIPC` pods remain:
             ```bash theme={null}
             for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
               echo "Namespace: $ns"
               kubectl get pods -n "$ns" -o json | \
                 jq -r '.items[] | select(.spec.hostIPC==true) | .metadata.name' || true
             done
             ```
      </Accordion>

      <Accordion title="Using kubectl">
        ### Using kubectl

        #### 1. List pods using `hostIPC`

        Run on: any machine with kubectl access.

        ```bash theme={null}
        kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOST_IPC:.spec.hostIPC' \
          | grep -E 'true|HOST_IPC'
        ```

        Output indicating a problem:

        * Any line (other than the header) where `HOST_IPC` is `true` is a pod sharing the host IPC namespace and must be reviewed.

        To see full spec for a specific pod:

        ```bash theme={null}
        kubectl get pod POD_NAME -n NAMESPACE -o yaml
        ```

        Check:

        * `.spec.hostIPC: true` → this pod is sharing host IPC.

        ***

        #### 2. See current Pod Security Admission labels on namespaces

        Run on: any machine with kubectl access.

        ```bash theme={null}
        kubectl get ns -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce,WARN:.metadata.labels.pod-security\.kubernetes\.io/warn'
        ```

        Output indicating a problem (with respect to host IPC restriction):

        * Namespaces that run user workloads and:
          * Have `ENFORCE` unset or set to `privileged` may allow `hostIPC: true` unless other policies exist.
          * Use `baseline` instead of `restricted` may still allow some higher-risk options; verify separately with your policy requirements.

        You must decide:

        * Which namespaces should be hardened (e.g., `enforce=restricted`).
        * Whether any `hostIPC: true` pods are strictly necessary for their workloads.

        ***

        #### 3. Check for namespace-level policies that might already restrict `hostIPC` (optional deeper review)

        If you use Gatekeeper/OPA or other policy engines, list their constraints (example for Gatekeeper):

        ```bash theme={null}
        kubectl get constrainttemplates.constraints.gatekeeper.sh
        kubectl get constraints.gatekeeper.sh -A
        ```

        Output indicating a problem:

        * No constraints referencing `hostIPC` or similar fields means nothing (beyond Pod Security Admission) is limiting host IPC usage, so `hostIPC: true` pods you found are likely admitted without additional controls.

        ***

        These commands only surface the current state. A human must review which `hostIPC: true` pods are justified and whether namespace labels and policies are appropriate for your risk tolerance.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report pods using hostIPC and namespace Pod Security labels
        # Run on: any machine with kubectl access and current context set

        set -o errexit
        set -o nounset
        set -o pipefail

        echo "=== Namespace Pod Security labels (enforce/warn) ==="
        kubectl get ns \
          -o custom-columns=NAME:.metadata.name,ENFORCE:'.metadata.labels.pod-security\.kubernetes\.io/enforce',WARN:'.metadata.labels.pod-security\.kubernetes\.io/warn' \
          | sed 's/<none>//g'

        echo
        echo "=== Pods requesting hostIPC=true (cluster-wide) ==="
        kubectl get pods --all-namespaces -o json \
          | jq -r '
            .items[]
            | select(.spec.hostIPC == true)
            | [
                .metadata.namespace,
                .metadata.name,
                (.metadata.ownerReferences[0].kind // "Pod"),
                (.metadata.ownerReferences[0].name // "N/A")
              ]
            | @tsv
          ' 2>/dev/null \
          | awk 'BEGIN { OFS="\t"; print "NAMESPACE","POD","OWNER_KIND","OWNER_NAME" } { print }'

        echo
        echo "=== Summary: count of pods with hostIPC=true per namespace ==="
        kubectl get pods --all-namespaces -o json \
          | jq -r '
            [ .items[] | select(.spec.hostIPC == true) | .metadata.namespace ] 
            | group_by(.) 
            | map({ns: .[0], count: length}) 
            | sort_by(.ns) 
            | .[] 
            | "\(.ns)\t\(.count)"
          ' 2>/dev/null \
          | awk 'BEGIN { OFS="\t"; print "NAMESPACE","HOSTIPC_POD_COUNT" } { print }'

        echo
        echo "=== Detail: pods with hostIPC=true and their containers ==="
        kubectl get pods --all-namespaces -o json \
          | jq -r '
            .items[]
            | select(.spec.hostIPC == true)
            | . as $pod
            | $pod.spec.containers[]
            | [
                $pod.metadata.namespace,
                $pod.metadata.name,
                .name,
                ($pod.metadata.labels."app" // ""),
                ($pod.metadata.labels."app.kubernetes.io/name" // "")
              ]
            | @tsv
          ' 2>/dev/null \
          | awk 'BEGIN { OFS="\t"; print "NAMESPACE","POD","CONTAINER","APP_LABEL","APP_K8S_NAME_LABEL" } { print }'
        ```

        Explanation of output indicating a problem:

        * In “Pods requesting hostIPC=true” and “Detail: pods with hostIPC=true and their containers”:
          * Any listed pod is a potential issue. Each such pod should be reviewed to determine if hostIPC is strictly necessary.
        * In “Summary: count of pods with hostIPC=true per namespace”:
          * Namespaces with non‑zero `HOSTIPC_POD_COUNT` require review; high counts suggest broader policy gaps.
        * In “Namespace Pod Security labels”:
          * Namespaces running user workloads that:
            * lack `pod-security.kubernetes.io/enforce=restricted`, or
            * have no `ENFORCE` label at all,
              should be evaluated. If workloads do not require hostIPC or other privileged features, consider enforcing the `restricted` profile (or stronger controls via alternative mechanisms).
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>