- Test admission policy against both rejected and permitted workloads.
- Verify network-policy enforcement with your actual cluster networking implementation.
- Preserve deployment identity and image digests so an incident can be reconstructed.
An image scan can tell you about known vulnerable packages. It cannot tell you whether the deployed workload can read another application's secrets, reach the Kubernetes API unnecessarily, or mount a host directory. Review the running configuration as well as the image.
The Kubernetes security checklist provides a useful baseline for cluster and workload controls. Apply it to one representative service first, including its deployment pipeline and the people who can change it.
Inspect the effective workload configuration
Choose a service with an identified owner. Record the image digest, namespace, service account, security context, mounted volumes, secrets, and exposed ports. Inspect what runs after admission and mutation, not only the manifest in a repository.
Look for privileged mode, unnecessary capabilities, host namespace access, writable paths, and host-mounted directories. Check whether the process can run without root and whether a read-only root filesystem is practical. Applications may need specific writable directories; give those paths explicit storage rather than making the whole filesystem writable for convenience.
Review workload identity separately. A container that cannot become root may still have a service account authorized to read secrets or assume a powerful cloud role. Remove unused token mounting where appropriate and limit permissions to the resources the service requires.
Make admission failures understandable
Use admission policy to catch prohibited deployment settings before release. Kubernetes Pod Security Admission supports audit, warning, and enforcement modes. Start with the evidence needed to understand existing violations, then agree on enforcement and exception ownership.
In a nonproduction namespace, submit an intentionally noncompliant test workload and verify rejection. Also deploy the expected application configuration to confirm it still works. Capture the policy result in the delivery workflow so developers receive a fixable explanation.
Do not assume built-in Pod Security controls verify image signatures, provenance, or every registry restriction. Those requirements need appropriate additional controls. Record any exception with an owner and expiry; otherwise a temporary deployment workaround can become the default.
Prove the network boundary
Kubernetes NetworkPolicy enforcement requires a supporting network plugin. Creating a policy object alone does not establish that traffic is blocked.
For a hypothetical invoice-processing service, define the necessary database, DNS, queue, and external API connections. In a test environment, verify those flows and attempt a connection to an unrelated service that should be denied. Check ingress and egress separately. Be explicit about controls for cloud metadata and destinations outside the cluster; capabilities vary by implementation.
Namespaces organize workloads but do not, on their own, prove strong isolation. Decide whether services with materially different trust requirements need stronger node or cluster separation.
Preserve the record of a deployment
An incident review needs to connect the running image digest to its build, deployment actor, configuration changes, and workload identity. Retain relevant registry, pipeline, Kubernetes audit, and runtime records outside the affected workload's writable storage.
Use an authorized test deployment to check that the responder can reconstruct who released it and what changed. Avoid recording secret values in logs or debug bundles. Verify that old workload logs survive pod replacement for the period the investigation plan requires.
Assign the resulting fixes to the appropriate owner: platform for admission and cluster policy, application engineering for runtime requirements, and security or operations for evidence collection. A release is ready when the allowed behavior works and the prohibited behavior has been tested, not merely when the scanner is quiet.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.