CPU and memory resource limits defined for all pods
Why it matters
Containers without resource limits can consume unbounded CPU and memory — a runaway process, a traffic spike, or a memory leak starves other pods on the same node, triggering cascading OOM kills and node instability (CIS Kubernetes 5.7.4, ISO 25010 performance efficiency). Without resource requests, the Kubernetes scheduler has no data for placement decisions, leading to uneven node utilization and unexpected evictions under load. A single container with no memory limit can consume all memory on a node and bring down unrelated production workloads.
Severity rationale
Low because unbounded resource consumption primarily causes availability impact through node exhaustion rather than enabling direct data access or privilege escalation.
Remediation
Define both requests and limits for CPU and memory on every container in k8s/deployment.yaml. Size requests based on typical load and limits based on the worst-case load the application can handle before it's better to restart than to degrade:
containers:
- name: api
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
For initial sizing, deploy without limits in a staging environment and observe actual usage with kubectl top pods. Set limits at 2x the 95th-percentile observed usage. Use LimitRange objects to enforce defaults at the namespace level so new containers cannot be deployed without resource constraints.
Detection
-
ID:
resource-limits -
Severity:
low -
What to look for: Count every container across all Kubernetes Deployments, StatefulSets, and DaemonSets. For each container, check whether both
resources.requestsandresources.limitsare defined for CPU and memory. Verify limits are reasonable: CPU limits under 4000m and memory limits under 4Gi for typical stateless services. -
Pass criteria: Every container in every Deployment and StatefulSet defines both
resources.requestsandresources.limitsfor CPU and memory. Limits are set to reasonable values (e.g., CPU under 4000m, memory under 4Gi for stateless services). Report the count: "X of Y containers have both request and limit defined." -
Fail criteria: Any container lacks resource requests or limits, or limits are set to unreasonably high values (e.g., memory over 16Gi for a stateless web service).
-
Skip (N/A) when: The project does not use Kubernetes.
-
Detail on fail: Quote the container and missing fields. Example:
"Deployment 'api' container 'main' defines resource requests but no limits. Container could consume unlimited node resources."or"Memory limit is 16Gi for a stateless web service — unusually high" -
Remediation: Define resource requests and limits:
resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512MiSet appropriate values based on your application's typical behavior. Monitor and adjust as needed.
External references
- iso-25010:2011 · performance-efficiency — Performance Efficiency / Resource Utilization
- external · CIS-Kubernetes-5.7.4 — CIS Kubernetes Benchmark §5.7.4 — The default namespace should not be used
Taxons
History
- 2026-04-18·v1.0.0·Initial import from infrastructure-hardening·automated