Skip to main content

More Info:

Verifies readOnlyRootFilesystem is true. A writable root filesystem lets an attacker persist tools or modify binaries inside a running container.

Risk Level

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify noncompliant Pods (run on any machine with kubectl access):
  2. For each listed Pod, edit the owning workload manifest (e.g., Deployment) to set a read-only root filesystem (run on any machine with kubectl access; example for a Deployment):
    In the opened spec, under each .spec.template.spec.containers[] (and .initContainers[] if present) add or modify:
    Save and exit to apply the change.
  3. If the container needs a writable path, add an emptyDir volume and mount it there (run on any machine with kubectl access; continue in the same edit):
    • Under spec.template.spec.volumes:
    • Under the container that needs write access:
    Adjust name and mountPath to match the application’s needs. Do not remove readOnlyRootFilesystem: true.
  4. For Pods created directly (no controller), update or recreate their manifests (run on any machine with kubectl access):
    • Export the Pod spec:
    • Edit the file, adding:
      under each container and initContainer, and optionally add emptyDir + volumeMounts as in step 3.
    • Delete and recreate:
  5. Allow the workloads to roll out the updated Pods and confirm all Pods are running (run on any machine with kubectl access):
  6. Verification (run on any machine with kubectl access):
    The output should be is_compliant=true when all applicable containers use a read-only root filesystem.
On any machine with kubectl access:
  1. Edit the Pod’s controller manifest (Deployment example)
In /tmp/deploy.yaml, under each container (and initContainer) that should be read‑only, add or update:
Apply the updated manifest:
Repeat the same pattern for other controllers (StatefulSet, DaemonSet, CronJob, Job) by replacing deploy and the kind in the kubectl get call.
  1. Directly patch a running Pod (only if it is not controlled by a Deployment/StatefulSet/etc.)
Adjust the container index /0/ or patch additional containers as needed.If a Pod-level initContainer also needs the setting:
  1. Verification
Run the benchmark audit command again from any machine with kubectl access: