Container security is not only image scanning. Teams need runtime limits, workload identity, network boundaries, admission controls, secrets handling, and Kubernetes evidence before production incidents.
- Treat image scanning as one control, not the whole container security program.
- Limit runtime privilege, secrets access, workload identity, host access, and network movement.
- Preserve Kubernetes audit, registry, runtime, deployment, and cloud identity evidence.
Image scanning is only the first control
Container programs often start with image scanning. That is useful, but it does not answer the full security question. A clean image can still run with too much privilege, too much network access, weak secrets handling, or no useful logging.
NSA and CISA's Kubernetes hardening guidance points defenders toward vulnerability scanning, least privilege, network separation, strong authentication, and log auditing. The operating question is how those controls survive real deployment pressure.
Limit what the workload can do
Start with runtime behavior:
- run as non-root where possible
- avoid privileged containers
- drop unnecessary Linux capabilities
- use read-only root filesystems where the application supports it
- restrict hostPath mounts
- avoid host network and host PID unless clearly required
- separate higher-risk workloads from sensitive workloads
These controls reduce the blast radius when an application or dependency is compromised.
Treat admission policy as a guardrail
Admission controls can stop risky workloads before they run. Policies may check for privileged mode, missing resource limits, disallowed registries, unsigned images, exposed host paths, or missing labels.
The policy should be strict enough to matter and clear enough that developers know how to fix violations. A policy nobody understands will be bypassed or disabled under delivery pressure.
Separate secrets from images and environment sprawl
Secrets should not live in container images, source repositories, or long-lived environment variables without review.
Review:
- where secrets are stored
- who can read them
- whether workloads receive only the secrets they need
- how rotation works
- whether secrets appear in logs, crash output, or debug bundles
- whether service accounts are over-permissioned
Workload identity should be scoped like any other privileged access path.
Use network policy and egress control
Flat network access inside a cluster can make compromise worse. Workloads should not be able to talk to every namespace, database, metadata endpoint, or external service by default.
Useful boundaries include:
- namespace-level segmentation
- service-to-service allow lists
- restricted egress for sensitive workloads
- controlled access to cloud metadata services
- separate nodes or clusters for workloads with different trust levels
Network policy is not a substitute for application security, but it limits attacker movement.
Keep evidence before you need it
Kubernetes and container incidents require logs from multiple layers:
- Kubernetes audit logs
- admission controller decisions
- image registry events
- workload identity activity
- container runtime alerts
- node and control-plane logs
- network flow logs
- deployment and CI/CD events
If those records are not retained and query-ready, the team may not be able to reconstruct what changed or which workload was affected.
Container security is an operating model
The strongest container programs connect build, deploy, runtime, identity, networking, and evidence. Scanners help, but they are not the program. The program is the set of controls that prevent risky workloads, limit compromised workloads, and preserve enough evidence to respond.
Use the visual as a reminder to separate confirmed facts, scope, containment, and recovery decisions.
Incidents often begin with a message, token, reset workflow, or account recovery path that deserves fast validation.
Backups matter when the team can prove what can be restored, by whom, and within which business deadline.
How to use this container security guidance
Kubernetes clusters, containerized applications, CI/CD pipelines, image registries, runtime policies, workload identity, and cloud-native platforms.
The team can inspect image sources, workload manifests, admission policy, runtime privileges, network boundaries, secrets, and cluster logs.
Get specialist help when production clusters run privileged workloads, share sensitive namespaces, lack audit logs, or expose workloads to the internet.
- Container image provenance, scan results, registry events, admission decisions, and deployment history.
- Pod security settings, runtime privileges, workload identity permissions, secrets access, and network policy.
- Kubernetes audit logs, node/runtime events, control-plane changes, and cloud identity activity.
DefendArm Container Runtime Control Review
Move beyond image scanning by checking what workloads can do after deployment and what evidence exists if they are compromised.
- Build: verify image source, dependencies, signatures, and fixable vulnerabilities.
- Admit: enforce policy before risky workloads run.
- Run: limit privilege, filesystem write access, host access, and workload identity.
- Segment: constrain service-to-service traffic and cloud metadata access.
- Investigate: retain audit, runtime, identity, and deployment evidence.
- Questions to ask ITWhich systems, identities, data paths, and owners are involved, and where would an attacker or mistake create business impact?
- Signals to verifyConfirm access changes, policy exceptions, logging coverage, risky events, and any gaps that would slow investigation.
- Artifacts to produceCreate a short control map with owner, evidence, exception, review date, and the decision needed from leadership.
- Owner to assignAssign one technical owner, one business owner, and one person accountable for evidence and follow-up.
- Treating image scanning as the whole container security program.
- Allowing privileged pods, broad service accounts, or host mounts without a current reason.
- Skipping network policy because the cluster is internal.
- Missing audit logs and deployment records needed to reconstruct a cluster incident.
Use these references for the article's container and Kubernetes guidance on runtime hardening, workload isolation, admission controls, and audit evidence.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.