Minimize The Admission Containers Wishing Share The Host

More Info:

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

Risk Level

High

Address

Security

Compliance Standards

APRA CPS 234 (Australia)
BSI C5 (Germany)
Brazil LGPD
CCPA / CPRA (California)
CIS AKS
CIS Critical Security Controls v8
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

Remediation

Manual Steps

Identify namespaces that should host only restricted workloads
- On any machine with kubectl access:
```
kubectl get ns --show-labels
```
- Decide which namespaces are:
  - User/workload namespaces that should not allow hostIPC: true (e.g., dev, test, prod apps).
  - System or infrastructure namespaces that may legitimately need elevated privileges (e.g., kube-system, CNI, monitoring). Document any namespace that truly needs hostIPC.
Review existing pods using hostIPC to understand current risk
- On any machine with kubectl access, for each namespace of interest (replace NAMESPACE):
```
kubectl get pods -n NAMESPACE -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.name}{"\n"}{end}'
```
- If any pods are listed, inspect them to determine if hostIPC is actually required:
```
kubectl get pod POD_NAME -n NAMESPACE -o yaml
```
- For each such pod/workload, decide whether hostIPC is justified (e.g., low-level debugging/observability) or can be removed by updating the pod template (Deployment/DaemonSet/Job).
Plan and apply label-based Pod Security admission for restricted namespaces
- For each user/workload namespace where hostIPC should not be allowed, enforce the restricted policy level:
```
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
```
- Optionally, for all namespaces to get early warnings before enforcement, apply a baseline warning label:
```
kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
```
- Ensure any namespace that must continue to allow hostIPC is explicitly documented and not labeled with an enforcement level that would break required workloads, or is handled via separate policy/IaC.
Update workload definitions that still request hostIPC in restricted namespaces
- On any machine with kubectl access, list controllers that may be creating hostIPC pods in a given namespace:
```
kubectl get deploy,ds,sts,job,cronjob -n NAMESPACE -o wide
```
- For each controller suspected of using hostIPC, inspect the spec:
```
kubectl get deploy DEPLOYMENT_NAME -n NAMESPACE -o yaml | grep -n 'hostIPC' -n
```
- If hostIPC: true is found and not strictly required, remove it from the manifest in your Git/IaC source and redeploy, or patch directly (temporary fix) by editing:
```
kubectl edit deploy DEPLOYMENT_NAME -n NAMESPACE
```
  and delete the hostIPC: true field from the pod template.

Re-verify that restricted namespaces and workloads comply

Confirm labels are correctly set:

kubectl get ns -L pod-security.kubernetes.io/enforce -L pod-security.kubernetes.io/warn

Confirm no pods with hostIPC remain in namespaces where it should be disallowed:

for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "Namespace: $ns"
  kubectl get pods -n "$ns" -o jsonpath='{range .items[?(@.spec.hostIPC==true)]}{.metadata.name}{"\n"}{end}' || true
  echo "----"
done

Investigate and remediate any remaining pods listed in namespaces that are intended to be restricted.

Test and document admission behavior for future workloads
- Attempt to create a test pod with hostIPC: true in a namespace labeled with pod-security.kubernetes.io/enforce=restricted to confirm rejection:
```
cat <<'EOF' | kubectl apply -n NAMESPACE -f -
apiVersion: v1
kind: Pod
metadata:
  name: hostipc-test
spec:
  hostIPC: true
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.9
EOF
```
- Verify that creation fails due to policy. Capture the error and update your operational/runbook documentation to record which namespaces forbid hostIPC, and the process to request an exception if truly needed.

Using kubectl

1. List namespaces and their Pod Security labels
Run on: any machine with kubectl access.

kubectl get ns --show-labels

Problem indication:

Namespaces that host user workloads and either:
- Have no pod-security.kubernetes.io/enforce label, or
- Have pod-security.kubernetes.io/enforce set to privileged or baseline, not restricted.

To inspect a specific namespace:

kubectl get ns NAMESPACE -o yaml

Check .metadata.labels for pod-security.kubernetes.io/enforce and pod-security.kubernetes.io/warn.

2. Find pods using hostPID
Run on: any machine with kubectl access.

All namespaces:

kubectl get pods -A -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Per namespace:

kubectl get pods -n NAMESPACE -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.name}{"\n"}{end}'

Problem indication:

Any non-infrastructure, non-security, or general application pod listed here is a candidate problem: it is running with hostPID: true.

To inspect a specific pod:

kubectl get pod POD_NAME -n NAMESPACE -o yaml

Look for:

spec:
  hostPID: true

3. Identify workloads that could create hostPID pods
Run on: any machine with kubectl access.

Deployments:

kubectl get deploy -A -o yaml | grep -C5 "hostPID"

DaemonSets:

kubectl get daemonset -A -o yaml | grep -C5 "hostPID"

StatefulSets:

kubectl get statefulset -A -o yaml | grep -C5 "hostPID"

Problem indication:

Any user workload controller (in user namespaces) whose pod template includes hostPID: true may conflict with the goal of minimizing such containers.

4. Check namespace-level Pod Security admission behavior (dry-run)
Run on: any machine with kubectl access.

Test a hostPID pod against a namespace (no creation due to dry-run):

kubectl apply -n NAMESPACE --dry-run=server -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: ps-hostpid-test
spec:
  hostPID: true
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.9
EOF

Interpretation:

If the dry-run succeeds with no errors, the namespace currently allows hostPID (or is not enforcing restricted).
If you see rejection errors referring to Pod Security admission and restricted level, the namespace policies are preventing hostPID pods, which is generally desired for user workloads.

Use these outputs to decide, manually, which namespaces should enforce stricter policies and which workloads (if any) legitimately require hostPID.

Automation

#!/usr/bin/env bash
#
# Report pods using hostIPC and namespace-level pod security labels
# Runs with: any machine with kubectl access and current-context set
# Requires: kubectl, jq

set -euo pipefail

echo "=== 1) Namespaces and Pod Security labels (enforce/warn) ==="
kubectl get ns -o json \
  | jq -r '
    .items[]
    | {
        name: .metadata.name,
        enforce: .metadata.labels["pod-security.kubernetes.io/enforce"],
        warn: .metadata.labels["pod-security.kubernetes.io/warn"]
      }
    | [.name, ( .enforce // "<none>" ), ( .warn // "<none>" )]
    | @tsv' \
  | column -t \
  | sed '1iNAMESPACE\tPOD-SECURITY-ENFORCE\tPOD-SECURITY-WARN'

echo
echo "=== 2) Pods requesting hostIPC per namespace ==="
# List only pods where spec.hostIPC == true
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.hostIPC == true)
    | [
        .metadata.namespace,
        .metadata.name,
        .spec.serviceAccountName // "<default>",
        ( .metadata.ownerReferences[0].kind // "<none>" ),
        ( .metadata.ownerReferences[0].name // "<none>" )
      ]
    | @tsv' \
  | sort \
  | ( sed '1iNAMESPACE\tPOD\tSERVICEACCOUNT\tOWNER-KIND\tOWNER-NAME' || true ) \
  | column -t

echo
echo "=== 3) Summary: namespaces with user pods using hostIPC and their enforcement level ==="
# Heuristic: treat kube-system and kube-public as system namespaces; others as user namespaces.
USER_NS_EXCLUDE_REGEX='^(kube-system|kube-public|kube-node-lease)$'

# Build a map of namespace -> enforce label
ns_labels_json="$(kubectl get ns -o json)"

kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.spec.hostIPC == true)
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        sa: .spec.serviceAccountName // "<default>",
        ownerKind: ( .metadata.ownerReferences[0].kind // "<none>" ),
        ownerName: ( .metadata.ownerReferences[0].name // "<none>" )
      }' \
  | jq -rs --argjson nsLabels "${ns_labels_json}" '
    def ns_enforce_label($ns):
      ($nsLabels.items[] | select(.metadata.name == $ns) | .metadata.labels["pod-security.kubernetes.io/enforce"]) // "<none>";
    [
      .[]
      | . + { enforce: ns_enforce_label(.ns) }
    ]
    | .[]
    | [.ns, .pod, .sa, .ownerKind, .ownerName, .enforce]
    | @tsv' \
  | awk -v re="$USER_NS_EXCLUDE_REGEX" '
      BEGIN {
        print "NAMESPACE\tPOD\tSERVICEACCOUNT\tOWNER-KIND\tOWNER-NAME\tENFORCE-LABEL";
      }
      {
        ns=$1;
        if (ns ~ re) {
          # Likely system namespace; still printed but can be visually distinguished
          print $0 "\t(SYSTEM-NS)";
        } else {
          print $0;
        }
      }' \
  | column -t

How to interpret the output

Section 1 – Namespace labels
- Problem indicators:
  - Namespaces hosting user workloads that lack pod-security.kubernetes.io/enforce=restricted.
  - Namespaces missing pod-security.kubernetes.io/enforce entirely (shown as <none>).
Section 2 – Pods using hostIPC
- Problem indicators:
  - Any pod in a user namespace (not obviously system, e.g. not kube-system, kube-public, kube-node-lease) listed here has spec.hostIPC: true and should be reviewed.
  - Pay special attention to long-lived workloads (e.g., Deployments, StatefulSets, DaemonSets) via the OWNER-KIND/OWNER-NAME columns.
Section 3 – hostIPC pods vs. enforcement
- Problem indicators:
  - Rows where:
    - Namespace is a user namespace (no (SYSTEM-NS) suffix in the last column), and
    - ENFORCE-LABEL is <none> or weaker than your policy goal (benchmark suggests restricted).
- These are the concrete cases to manually review and decide whether to:
  - Remove hostIPC from the workload spec, and/or
  - Tighten namespace labels using:
    - kubectl label --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted
    - kubectl label --overwrite ns <namespace> pod-security.kubernetes.io/warn=baseline

This script only reports and does not change any resources, so final policy decisions and fixes remain manual as required by the benchmark.

Additional Reading:

https://kubernetes.io/docs/concepts/security/pod-security-standards/

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​

Using kubectl​

Additional Reading:​

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Using kubectl

Additional Reading: