Container and Image Hardening

What this finding is

Container workloads depart from hardening guidance — running as root, built on full operating-system base images carrying substantial unnecessary surface, lacking resource limits, running with unnecessary Linux capabilities, or permitting writable root filesystems. Also covers images without provenance or signature verification.

Why it is Tier 3

Container hardening constrains what an application compromise yields. A non-root container with dropped capabilities and a read-only filesystem substantially raises the cost of turning code execution into host access, but none of these settings prevents the initial compromise. The work is also naturally incremental — each image can be hardened independently — which fits the Tier 3 profile of continuous background investment.

How to detect it

1. 1Scan image manifests for root user, missing resource limits, and unnecessary capabilities.
2. 2Assess base image size and package count; minimal and distroless bases materially reduce surface.
3. 3Run a Kubernetes benchmark (kube-bench) and check whether pod security standards are enforced.
4. 4Confirm images are signed and that verification is enforced at admission rather than merely available.

How to remediate it

Steps are ordered. The first step is the one that reduces exposure fastest, which is not always the one that closes the finding.

1. 1Add a non-root user to images and set the runtime user explicitly; this is the single highest-value change.
2. 2Migrate to minimal or distroless base images, which reduces both attack surface and vulnerability-scan noise.
3. 3Set resource limits, drop all capabilities and re-add only those required, and mount root filesystems read-only.
4. 4Enforce pod security standards at the namespace level so new workloads inherit the constraints.
5. 5Enable signature verification at admission so unsigned images cannot run.

How to verify the fix

Mappings

Other Tier 3 findings in Processing Protection