Skip to main content

More Info:

Verifies every container sets resources.requests so the scheduler can place the pod correctly and QoS is not BestEffort.

Risk Level

Low

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. On any machine with kubectl access, list all non-compliant containers (those without CPU or memory requests):
  2. For each affected Pod, identify whether it is controlled by a higher-level object (Deployment, DaemonSet, StatefulSet, Job, CronJob, etc.):
    • If there is an ownerReference, you must edit the owner (e.g., Deployment), not the Pod.
    • If there is no ownerReference, edit the Pod directly.
  3. For Pods controlled by a higher-level controller (example: Deployment), edit the controller spec and add CPU and memory requests for each container:
    In the opened manifest, under each spec.template.spec.containers[].resources, ensure something like:
    Save and exit; the controller will roll out new Pods with the defined requests.
  4. For standalone Pods (no ownerReference), patch them to add CPU and memory requests for a specific container (repeat per container as needed):
    Adjust the container index in /spec/containers/0/... and request values as appropriate for your workload.
  5. For workloads managed via manifests/IaC (e.g., GitOps, Helm, Terraform), locate and edit the source manifest instead of using kubectl edit, then apply:
    Ensure each container spec in the source includes resources.requests.cpu and resources.requests.memory before applying.
  6. Verification (on any machine with kubectl access): after changes roll out, rerun the compliance check and confirm is_compliant=true or no rows with is_compliant=false:
    Confirm that all listed containers show non-unset requestsCpu and requestsMemory and is_compliant=true.
On any machine with kubectl access:
  1. Identify non‑compliant pods and their controllers
This lists unique <namespace> <ownerKind> <ownerName> you need to edit (e.g. default Deployment myapp).
  1. Export the controller manifest, add requests, and re‑apply
Example for a Deployment named myapp in namespace default:
Edit myapp-patched.yaml and, under each container, add resources.requests.cpu and resources.requests.memory if missing, for example:
Apply the updated manifest:
Repeat these steps for each non‑compliant controller kind (Deployment, StatefulSet, DaemonSet, Job, CronJob, etc.). For standalone Pods you manage directly, export/edit/apply similarly:
  1. Verify remediation
Run the benchmark audit command again from any machine with kubectl access:
Confirm either is_compliant=true overall or that all listed containers now show non‑unset requestsCpu and requestsMemory with is_compliant=true.