Container declares no CPU or memory limit

ID

missing_resource_limits

Severity

low

Remediation Complexity

trivial

Remediation Risk

low

Remediation Effort

low

Vendor

Kubernetes

Resource

General Security

Tags

ASVS50:v13.1.1, CWE:770, reachable

Description

A container declares no resources.limits.cpu and no resources.limits.memory, so nothing bounds what it may take from the node.

One container in a loop, or one leaking memory, then degrades or evicts every other workload sharing that node — the noisy-neighbour failure, and the shape a denial of service takes inside a cluster (CWE-770). A limit is also what makes the failure legible: the container is killed or throttled rather than the node going unhealthy for reasons nobody can attribute.

Both limits are required to clear this rule. Bounding CPU alone still leaves memory unbounded, and memory is the one that gets a node evicted.

Examples

Reported:

spec:
  containers:
    - name: worker
      image: example/worker:1.4.2

Also reported — CPU alone leaves memory unbounded:

      resources:
        limits:
          cpu: "1"

And reported — the keys are there but nothing is set. This is what a Helm chart renders when .Values.resources.limits.* has no value, and the container is as unbounded as if the block were absent:

      resources:
        limits:
          cpu:
          memory:

The rule covers initContainers as well as containers. It does not cover ephemeralContainers: Kubernetes rejects a resources block on one, so a limit cannot be declared there and reporting its absence would be a flaw no manifest could fix.

Mitigation / Fix

Declare both limits, and requests alongside them so the scheduler can place the pod honestly:

spec:
  containers:
    - name: worker
      image: example/worker:1.4.2
      resources:
        requests:
          cpu: "250m"
          memory: 256Mi
        limits:
          cpu: "1"
          memory: 512Mi

Where the same defaults suit a whole namespace, a LimitRange sets them once rather than repeating them in every manifest.

© 2026 Xygeni. All rights reserved