They should scan manifests in the delivery pipeline, block high-risk patterns, and route every finding to a named owner. The goal is to catch privileged execution, root containers, exposed secrets, and missing resource limits before the workload is scheduled. Static review works best when it is enforced, not just reported.
Why This Matters for Security Teams
Kubernetes manifest misconfigurations are often the first weak point in an otherwise well-governed container platform. A single bad manifest can approve privileged execution, mount host paths, expose secrets, or remove resource constraints that keep noisy or malicious workloads contained. That is why pre-deployment review belongs in the change path, not in post-incident analysis. The control objective is simple: stop unsafe intent before it becomes a running workload, then make accountability visible to the right owner. The NIST Cybersecurity Framework 2.0 is useful here because it frames secure configuration as an ongoing governance and protection activity, not a one-time checklist.
Teams often miss this because manifests are treated as developer output rather than security-relevant infrastructure code. That leads to gaps between what the cluster policy says and what actually gets deployed. Security review should therefore focus on repeatable controls, clear blocking rules, and fast feedback to the person who can fix the file. In practice, many security teams encounter these issues only after an exposed service or privileged pod has already created an incident, rather than through intentional prevention.
How It Works in Practice
Effective handling starts with policy-as-code in the CI or GitOps pipeline. The manifest should be evaluated before merge, before image promotion, and again before deployment if the final object can still be mutated by templating or overlays. Current guidance suggests combining static checks with admission-time enforcement so risky settings cannot slip through when a deployment path is reused across environments. This aligns well with secure configuration practices described in the CIS Controls and with cluster hardening principles from the kubernetes security ecosystem.
Common checks include:
- rejecting privileged containers, host namespace sharing, and hostPath mounts unless explicitly approved;
- blocking containers that run as root or lack a non-root security context;
- requiring read-only root filesystems where the workload allows it;
- verifying resource requests and limits to reduce denial-of-service risk and scheduler instability;
- detecting plaintext secrets, unsafe environment variable injection, and broad service account permissions;
- checking for missing probes, unsafe capabilities, and image references that are not pinned or trusted.
Finding severity should reflect workload impact, not just syntax. A manifest that exposes a secret or grants cluster-admin access is not a cosmetic issue. It should block deployment by default, open a ticket to a named owner, and preserve enough context for quick remediation. Where teams use GitOps, the enforcement point should be the controller or admission layer as well as the pull request workflow, because merge approval alone does not guarantee deployment safety. Kubernetes Pod Security Standards are a practical baseline for identifying patterns that should be denied or tightly constrained.
This guidance breaks down when manifests are generated dynamically across many overlays, because the final rendered object can differ from the reviewed source and create blind spots in policy coverage.
Common Variations and Edge Cases
Tighter manifest controls often increase pipeline friction, requiring organisations to balance deployment speed against the reduction in cluster risk. That tradeoff is real, especially for platform teams supporting many namespaces, tenants, or exception-driven workloads. Best practice is evolving on how much should be blocked automatically versus routed for approved exceptions, so teams should document where the line is drawn rather than assuming consensus exists.
Some environments need stricter handling than others. Regulated workloads may require immutable baselines, image allowlists, and explicit separation between developer namespaces and production admission policy. Ephemeral test clusters may tolerate looser policies, but only if they are isolated and short-lived. The most common edge case is a manifest that is individually acceptable but becomes dangerous when combined with other configuration, such as a benign-looking service account paired with broad RBAC or an init container that writes sensitive material into a shared volume.
Identity intersects here when workloads use non-human identities, workload tokens, or service accounts to reach cloud APIs or internal services. In those cases, the manifest review should include credential scope, token exposure, and whether the workload has more access than its function requires. There is no universal standard for every exception pattern yet, so teams should keep a decision log and periodically reassess recurring approvals. CISA Secure by Design is a useful lens for pushing security left into engineering choices rather than compensating later.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-5 | Manifest checks help prevent unsafe configuration from exposing data or secrets. |
| MITRE ATT&CK | T1611 | Privileged container settings can enable escape and lateral movement paths. |
| OWASP Non-Human Identity Top 10 | Kubernetes manifests often define workload identities and secret handling. |
Treat manifest review as a data-protection control and block configurations that expose sensitive material.
