Follow the build into the running workload

Retain the source revision, image digest, build record and deployment configuration. Compare them with what is actually running, including changes made outside the deployment process. Then identify access to the network, secrets, storage and administrative operations.

Cluster administration and application security are related, but they do not replace one another. A managed orchestrator does not choose the application’s service account or decide which customer data that account should reach. Those permissions still need an application owner and a test.

Separate workloads that need different access

In a fictional platform, a report generator and an image processor share an identity that can read reports. The image processor does not need that access. The shared identity has given it a permission that belongs to another workload.

Create separate, appropriately scoped identities and test from the running workloads. The report generator should still read its required data; the image processor should be denied. Renaming accounts or creating two configuration entries is not enough if both retain the same effective permissions.

Record the information needed to reproduce the deployment

The review should connect the build, deployment and runtime. A missing record at one stage makes it harder to explain whether the running workload is the one that was approved.

  • Build: source revision, builder, image digest and dependencies.
  • Deployment: approver, configuration and change history.
  • Identity: credential or federation, permitted resources and token lifetime.
  • Runtime: process privileges, writable paths, network access and secrets.
  • Operations: logs, health checks, updates and rollback owner.

Test the restrictions without disrupting production

Use a representative, controlled nonproduction environment to check required access and prohibited access. For credential rotation, confirm that the application receives the replacement and that the obsolete credential fails. Keep secrets out of logs, screenshots and the resulting evidence.

To check an admission gate, submit a deliberately nonconforming specification in a controlled assessment environment. Confirm rejection for the intended reason. If an emergency path is authorized, its use needs to be attributable and reviewed; it should not become an undocumented way around the gate.

Record the differences that still need checking

The test namespace or cluster may use different identity, network or policy settings from production. Record those differences and identify what must be checked before applying the result to production. Even an image with no known vulnerabilities can contain a faulty authorization rule or run with excessive privilege. Scanning is useful evidence about the image, but it does not settle the workload review.

Sources and reference editions

  1. NIST Secure Software Development Framework1.1, SP 800-218