Container and Kubernetes security: where the real exposure is

Most container security programmes start and end with image scanning, which addresses perhaps a quarter of the real exposure. Clusters are compromised through permissive RBAC, absent network policy, over-privileged workloads and exposed control planes far more often than through a CVE in a base image.

Images: necessary, not sufficient

• Minimal base images. Distroless or slim images remove most of the vulnerability surface by removing packages you never used.
• Scan at build and in the registry - and rescan, because an image built clean six months ago is not clean now.
• Provenance. Sign images and verify signatures at deploy, so the cluster runs what your pipeline built rather than whatever was pushed to the registry.
• Do not build secrets into images. They persist in layers even if a later layer deletes them.

Where clusters are actually lost

• RBAC that grants cluster-admin liberally because narrower roles were fiddly. Service accounts with broad permissions are the common path from one compromised pod to the whole cluster.
• Default service account tokens auto-mounted into every pod. Most workloads do not need API access at all - turn it off.
• No network policy. By default every pod can reach every other pod. A flat cluster network means one compromised container reaches your database.
• Privileged containers and host mounts - hostPath, hostNetwork, privileged: true. Each is a container escape waiting for a bug.
• Exposed control plane or kubelet, or an unauthenticated dashboard.
• Secrets as environment variables, visible in process listings and crash dumps.

The single highest-value hardening step in most clusters is not scanning - it is applying default-deny network policy and removing auto-mounted service account tokens. Both are configuration changes, not purchases.

Admission control is where policy becomes real

Scanning tells you an image is bad; admission control stops it running. Enforce at deploy: no privileged containers, no host namespace access, required resource limits, images only from approved registries, signature verification, and required security contexts (non-root, read-only root filesystem where feasible).

Roll out in audit mode first, review what would have been blocked, then enforce. Enforcing on day one on a live cluster breaks deployments and gets the whole policy reverted.

Runtime

Build-time controls cannot see a container that starts behaving oddly. Runtime detection watches for process execution that does not match the image, unexpected network connections, filesystem writes and privilege escalation attempts. It matters most for workloads you did not build and cannot fully vet.

Where compliance frameworks land

Most frameworks predate containers and speak of servers and networks. Map deliberately: image scanning and patching satisfy vulnerability management; RBAC satisfies access control; network policy satisfies segmentation; admission control satisfies secure configuration; and audit logs satisfy logging. State the mapping explicitly, because an assessor unfamiliar with Kubernetes will otherwise ask you to produce controls that do not apply.

Key takeaways

• Image scanning is the smallest part of container security.
• Permissive RBAC and flat pod networking are how clusters are actually lost.
• Admission control turns policy into enforcement - roll out in audit mode first.
• Map container controls to framework requirements explicitly.