Skip to main content

More Info:

hostPID=true allows a container to view and signal every process on the node, providing trivial paths to escape isolation. Reject pods with hostPID by default in admission policy.

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Using Console

In OKE this setting comes from the Kubernetes pod spec (hostPID: true). There is no single “toggle” in the OCI Console; you remediate by (1) finding the offending workloads and (2) redeploying them without hostPID, and optionally (3) enforcing a policy so it can’t be re‑introduced.Below are the steps, keeping everything driven from the OCI Console as much as possible.

1. Identify pods using the host PID namespace

  1. Sign in to the OCI Console.
  2. Go to Developer Services → Kubernetes Clusters (OKE).
  3. Select the Compartment, then click your Cluster.
  4. In the cluster details page, in the left menu, choose Workloads (if available in your console region/version):
    • Look at the Pod YAML (or the parent Deployment/DaemonSet/StatefulSet YAML) for suspicious workloads.
    • Check each pod’s spec for:
  5. If you don’t see it clearly in the GUI, use Cloud Shell from the console:
    • Click the Cloud Shell icon (top‑right).
    • Configure kubectl for your cluster by clicking Access Cluster in the cluster details page and following the on‑screen instructions to download and use the kubeconfig in Cloud Shell.
    • Then in Cloud Shell run:
    • This lists all pods with hostPID: true.
Note down which namespaces and controller types (Deployment, DaemonSet, Job, etc.) are responsible for those pods.

2. Remove hostPID: true and redeploy

For each offending controller (Deployment/DaemonSet/Job/etc.):
  1. In the OCI Console → OKE → your cluster → Workloads:
    • Locate the workload (Deployment/DaemonSet/Job) generating the pod.
    • Use View YAML to see its manifest.
  2. Open Cloud Shell again (from the OCI Console) and edit the manifest via kubectl:
    • Export the existing manifest:
    • Edit the file in Cloud Shell (e.g., using vi):
      • Find any line:
        and either remove it (default is false) or explicitly set:
    • Apply the updated manifest:
  3. For controllers you created via Helm or another CI/CD pipeline, update the source (Helm chart values or Git repo) to:
    • Remove/disable hostPID: true in their templates or values.
    • Redeploy from that system to avoid it being re‑introduced.
  4. Verify that no pods in the cluster now use the host PID namespace:
    If this returns nothing, the configuration issue is remediated.

OKE doesn’t offer a direct “disallow hostPID” switch in the console, but you can enforce it using Kubernetes’ built‑in Pod Security Admission (for clusters on recent Kubernetes versions):
  1. In Cloud Shell, label namespaces with a strict Pod Security level that disallows host namespaces (e.g., restricted):
    The restricted profile prohibits host namespace sharing (including hostPID).
  2. For system namespaces (like kube-system) you may need less strict policies; focus on your application namespaces.
  3. Test by trying to deploy a pod with hostPID: true in that namespace—it should now be rejected by the API server.

Summary of what you must do in OCI Console–driven flow
  • Use OKE cluster page + Cloud Shell to:
    • Discover pods with hostPID: true.
    • Edit and re‑apply their controller manifests to remove hostPID.
    • Optionally label namespaces with pod-security.kubernetes.io/enforce=restricted so future hostPID usage is blocked.
If you share your OKE/Kubernetes version, I can give the exact kubectl commands and sample manifests aligned to that version.
To remediate “Containers sharing the host PID namespace” in OCI OKE, you need to ensure hostPID: false (or absent) in all Pod specs. Using OCI CLI, the flow is:

1. Configure kubectl access via OCI CLI

If you don’t already have kubeconfig for the cluster:

2. Find Pods/Workloads using hostPID: true

Check current Pods:
Check higher‑level objects (Deployments, DaemonSets, StatefulSets, etc.) that might be creating such Pods:
(Assumes yq is installed; if not, you can inspect YAML manually.)

3. Remove / disable hostPID in the workload specs

For each workload identified:

Option A: Patch with kubectl (fastest)

Set hostPID: false on the Pod template:
Similar for other kinds:
You can drive this fully from OCI CLI by first generating kubeconfig (step 1) and then running these kubectl commands in the same shell.

Option B: Edit manifests and re‑apply

If you manage manifests/Helm charts in Git:
  1. In each Pod template, ensure:
  2. Re‑deploy:

4. Optionally enforce at policy level (prevent future drift)

OKE uses upstream Kubernetes; you can use Pod Security Admission (recommended) or Gatekeeper/OPA. Example (Kubernetes v1.25+ with Pod Security Admission):Create a namespace label to enforce restricted (which disallows hostPID):
This can also be done after kubeconfig creation from OCI CLI.

5. Verify remediation

Re‑run the check:
No output means no Pods are using hostPID: true.
In OKE this risk comes from pods that set hostPID: true in the pod spec. You remediate by finding all such workloads and patching them to hostPID: false (or removing the field), then enforcing a policy to prevent new ones.Below are step‑by‑step instructions and Python examples using the Kubernetes Python client against your OKE cluster.

1. Prereqs

  1. Install tools:
  2. Make sure your kubectl is already configured for the OKE cluster (e.g. via OCI Console “Access Cluster” instructions).
    The Python client will reuse that kubeconfig.
  3. Verify:

2. Python: Identify all resources using hostPID: true

This script scans common workload types (Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs) in all namespaces and prints where hostPID is enabled.
Run this to see all offenders.

3. Python: Remediate by patching hostPID to false

You should ideally fix the original manifests in Git/Helm first. But if you need to remediate live workloads via script, you can patch them like this.Below is an example for Deployments and StatefulSets (you can extend to other controllers similarly):
You can add similar blocks for:
  • apps_v1.patch_namespaced_daemon_set
  • apps_v1.patch_namespaced_replica_set
  • batch_v1.patch_namespaced_job
  • batch_v1.patch_namespaced_cron_job
  • Or patch individual Pods (not usually needed if controlled by a higher-level resource).

4. Prevent new hostPID usage (policy)

For long‑term remediation, you should block hostPID: true at admission time:
  1. If using Gatekeeper / OPA (or Kyverno), add a policy that denies any pod with spec.hostPID: true.
  2. Or use Kubernetes Pod Security Admission (PSA) with at least baseline / restricted profiles (which disallow host namespaces).
In OKE, you’d typically:
  • Enable Pod Security Admission in the cluster (if supported by your OKE/K8s version).
  • Set the namespace label, e.g.:
This will prevent future pods from using hostPID.

5. Validate

After the script and/or policy:
  1. Re-run the scanning script — it should find no hostPID: true.
  2. Try to deploy a test pod with hostPID: true; it should be rejected by policy (if configured).
If you share which controllers/resources you’re using (Helm, raw YAML, Operators), I can tailor a minimal Python script that only targets those.
This setting cannot be configured on the oci_containerengine_cluster (OKE cluster) resource in Terraform; OKE does not expose admission policy / hostPID controls at the cluster resource level.Rejecting pods with hostPID: true must be done via Kubernetes admission control objects inside the cluster (for example, Pod Security Admission, ValidatingAdmissionPolicy, or a validating webhook such as Gatekeeper/Kyverno), created with kubectl or via a Kubernetes Terraform provider. In the OCI Console you would:
  1. Get credentials for the OKE cluster and configure kubectl.
  2. Apply an admission policy (e.g., a ValidatingAdmissionPolicy or webhook) that denies any pod where spec.hostPID == true.