# CPU and memory resource limits defined for all pods

- **Pattern:** `ab-001648` (`infrastructure-hardening.monitoring-incident-response.resource-limits`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001648
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001648)

## 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:

```yaml
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.requests` and `resources.limits` are 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.requests` and `resources.limits` for 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:

  ```yaml
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  ```

  Set appropriate values based on your application's typical behavior. Monitor and adjust as needed.

## External references

- iso-25010 performance-efficiency
- external CIS-Kubernetes-5.7.4 — https://www.cisecurity.org/benchmark/kubernetes

Taxons: cost-efficiency, operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-001648