How should security teams implement policy as code across Kubernetes and Terraform?

Why This Matters for Security Teams

policy as code is attractive because it promises one source of truth, but Kubernetes and Terraform expose different choke points, timing, and failure modes. Kubernetes policy decisions happen at request time in a live control plane, while Terraform policy often runs earlier in a pipeline or plan review. If the same rule is not expressed consistently, teams get drift: one environment blocks the change, another allows it, and neither result is trustworthy.

For NHI-heavy infrastructure, that inconsistency matters because automation can create or expose secrets, service accounts, and access paths at machine speed. NHIMG research shows that 97% of NHIs carry excessive privileges and 71% are not rotated on time, which makes preventive policy far more important than manual review. The NIST Cybersecurity Framework 2.0 reinforces the need to manage risk continuously rather than only after deployment.

Practitioners usually underestimate how quickly policy fragmentation turns into governance gaps across CI/CD, cluster admission, and infrastructure provisioning. In practice, many security teams encounter policy drift only after an unexpected deployment or secret exposure has already occurred, rather than through intentional control testing.

How It Works in Practice

The cleanest model is to define policy once, evaluate it centrally, and enforce it at multiple layers. A common pattern is to write policy logic in Rego, keep it in version control, and use the same policy package for Kubernetes admission control, Terraform plan checks, and build pipeline gates. That gives teams consistent decisions even though the enforcement points differ.

For Kubernetes, policy typically sits at admission, where it can inspect labels, namespaces, image sources, resource requests, or service account bindings before objects land in the cluster. For Terraform, policy usually evaluates plans before apply, so teams can block dangerous IAM bindings, public exposure, weak encryption settings, or unapproved network routes before they become real infrastructure. This maps well to the lifecycle guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, especially where provisioning and revocation must be controlled as part of a larger identity workflow.

• Use one policy repository so the same rule is tested once and reused everywhere.
• Separate decision logic from enforcement, so Kubernetes, Terraform, and CI tools call the same policy engine.
• Version policies like application code, with review, testing, and rollback.
• Bind each rule to a named control or exception process so audit evidence is traceable.
• Test both allow and deny cases, including edge cases such as inherited permissions and default service accounts.

Current best practice is to make policy evaluation deterministic and observable. Logs should show which policy evaluated, what inputs were used, and why a request was denied. That is essential when teams need to explain why a cluster object was blocked while the corresponding infrastructure change was still permitted. The operational reality is that policy as code fails when organisations treat Kubernetes and Terraform as interchangeable, because their enforcement timings and available context are fundamentally different.

Common Variations and Edge Cases

Tighter policy enforcement often increases pipeline friction, requiring organisations to balance control strength against developer throughput. That tradeoff is real, especially when teams rely on rapid experimentation or have many legacy modules that were never designed for policy checks. Current guidance suggests starting with high-confidence controls first, then expanding coverage as policy tests and exception handling mature.

One common edge case is partial enforcement. Some teams gate Terraform but leave Kubernetes admission too permissive, which means unsafe changes can still be introduced manually or through other automation paths. Another is policy duplication, where platform teams copy rules into multiple engines and create inconsistent exceptions. The better pattern is to keep shared logic centralized and translate only the enforcement layer, not the policy intent.

There is no universal standard for how every organisation should split responsibilities between platform engineering, security engineering, and application teams. The State of Non-Human Identity Security notes that many organisations still lack full visibility into NHI-connected workflows, which makes policy ownership harder to sustain. The practical takeaway is to define who approves policy changes, who maintains exceptions, and who validates enforcement after each release. These controls tend to break down when ad hoc infrastructure changes bypass the pipeline because the policy never gets a chance to evaluate them.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?