Skip to main content

More Info:

Advisory: long-running containers should define livenessProbe and readinessProbe so Kubernetes can restart hung pods and keep traffic off pods that are not ready.

Risk Level

Informational

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify noncompliant pods and their owning controllers (run on any machine with kubectl access):
  2. For a pod managed by a controller (e.g., Deployment), edit the controller manifest to add probes (run on any machine with kubectl access). Example for a Deployment my-deploy in namespace my-namespace:
    In the spec.template.spec.containers[] entry for each long-running container, add something like:
    Adjust paths, ports, and timings to match the application.
  3. For a bare Pod without an owning controller (used only for testing or debugging), either:
    • Add probes directly by editing:
      then update the container spec with livenessProbe and readinessProbe as above, understanding this will not persist if the pod is recreated; or
    • Preferably, re-create it from a proper manifest:
      Edit /tmp/my-pod.yaml to:
      • Remove metadata.uid, metadata.resourceVersion, metadata.creationTimestamp, status, and any ownerReferences.
      • Add livenessProbe and readinessProbe under each long-running container. Then apply:
  4. If your workloads are managed through GitOps or IaC (e.g., manifests in OCI DevOps or a Git repo), make the same livenessProbe and readinessProbe additions in the source manifests for each long-running container, then let your normal deployment process apply them. This ensures changes are not overwritten.
  5. After edits, wait for the new pods to become Ready (run on any machine with kubectl access):
    Confirm that pods from updated controllers are in Running state and READY columns show all containers ready (e.g., 1/1, 2/2).
  6. Verify compliance (run on any machine with kubectl access):
    Confirm output is is_compliant=true or that no lines show is_compliant=false for long-running containers you expect to be covered.
On any machine with kubectl access:
  1. Identify non-compliant pods and their owners
  1. Edit the owning workload manifests and add probes
For workloads managed via kubectl manifests, edit the appropriate object (e.g. Deployment, StatefulSet, DaemonSet, Job, CronJob) and add both probes to each long‑running container.Example patch for a Deployment container (adapt paths/ports to your app):
If your container should use TCP or exec probes instead, adjust accordingly, for example:
For objects first defined in YAML, you can instead edit and re-apply:
  1. For bare Pods created directly (not recommended for long‑running apps)
Export, edit, and recreate with probes:
Edit my-pod.yaml:
  • Remove fields under metadata such as creationTimestamp, resourceVersion, uid, selfLink, managedFields.
  • Remove status: completely.
  • Under each long‑running spec.containers[], add livenessProbe and readinessProbe.
Then recreate:
  1. Verification
Run the original audit command and confirm all listed containers show is_compliant=true:
Usage (run on any machine with kubectl access):