IaC modernization is exposing cloud identity governance gaps

At a glance

What this is: This article argues that modern infrastructure as code now depends on modular design, policy enforcement, secrets handling, and drift detection to stay secure at scale.

Why it matters: It matters because IaC pipelines increasingly govern privileged cloud changes, so IAM, NHI, and platform teams must align identity controls with automated deployment workflows.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read ControlMonkey's guide to IaC modernization, policy checks, and secure pipelines

Context

Infrastructure as code turns cloud infrastructure into versioned code, but that shift also turns pipelines, modules, and repositories into identity enforcement points. When access keys, IAM roles, and policy checks sit inside the deployment path, weak governance can create the same operational risk as a direct console change.

The article’s core claim is that older IaC patterns break under larger teams, faster change rates, and AI-assisted code generation. For IAM and NHI teams, the real problem is not template generation itself but whether the surrounding controls still prove who can change infrastructure, who can approve it, and whether secrets remain out of source-controlled code.

Key questions

Q: How should teams govern secrets in infrastructure as code pipelines?

A: Teams should keep secrets out of code and move them into a dedicated runtime secrets service, then enforce policy that prevents repository storage and console exposure. The goal is to make credential lifecycle controls independent from the IaC repository, so revocation, rotation, and access review can happen without editing infrastructure templates.

Q: Why do reusable IaC modules change the IAM risk profile?

A: Reusable modules copy identity decisions across many accounts, so one privilege mistake can multiply quickly. That means IAM roles, trust policies, and network exceptions embedded in modules need stronger review than one-off changes, because the business impact scales with every reuse of the module.

Q: What do security teams get wrong about policy-as-code in cloud deployments?

A: They often treat policy-as-code as a compliance layer instead of an identity boundary. If the policy only checks syntax or obvious misconfigurations, it may miss excessive roles, hidden trust paths, or credentials that are still stored outside approved control points.

Q: How do teams know if drift detection is actually working?

A: Drift detection is working when it consistently surfaces out-of-band console changes, manual privilege changes, and configuration edits before they become accepted state. If alerts only show cosmetic differences, the control is missing the identity and entitlement changes that matter most.

Technical breakdown

Modular IaC architecture and reusable identity controls

Modular IaC breaks infrastructure into smaller building blocks that can be versioned, tested, and reused across teams. That matters because identity-related resources, such as IAM roles, security groups, and network guardrails, should be consistent rather than rewritten in each project. In practice, modules reduce drift in how access is expressed, but they also concentrate risk if a shared module carries a privilege mistake into many environments. Practical implication: treat identity-bearing modules as governed building blocks with ownership, review, and version discipline.

Practical implication: Review shared modules as identity-bearing assets, because one privilege error can replicate across many environments.

Policy-as-code for cloud access and compliance

Policy-as-code moves access rules out of tribal knowledge and into machine-enforced checks in the pipeline. The article points to controls such as blocking public SSH, requiring encryption, and validating approved images, which are all examples of encoding governance before deployment. For identity teams, the value is not just compliance, but making entitlement and configuration review happen before infrastructure exists. Practical implication: encode access and configuration rules early enough that a bad change cannot become a deployed state.

Practical implication: Put identity and configuration rules into the pipeline so non-compliant changes fail before deployment.

Secrets handling in IaC pipelines

Secrets handling is where IaC often breaks down first, because hardcoded credentials in Terraform files or repositories become durable exposures. The safer pattern is to fetch secrets at runtime from a dedicated secrets manager or secret agent, then keep them out of code, environment variables, and writable files wherever possible. That is an NHI control problem as much as a DevOps one, because the secret itself is a non-human identity credential with lifecycle, scope, and revocation requirements. Practical implication: separate credential storage from code and make runtime injection the default.

Practical implication: Keep credentials out of code and repositories, then inject them at runtime from controlled secrets services.

Threat narrative

Attacker objective: The objective is to turn infrastructure automation into a durable path for unauthorized cloud change, data exposure, or operational disruption.

1. Entry occurs when sensitive infrastructure credentials or unsafe configuration logic are introduced through code, repositories, or CI/CD workflows rather than controlled identity services.
2. Escalation happens when over-permissive modules, unreviewed changes, or hardcoded secrets let a change reach broader cloud privileges than intended.
3. Impact follows when those controls are used to create outages, expose data, or bypass governance through deployed infrastructure that looks valid but is mis-scoped.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IaC modernization is really an identity governance problem once cloud change is automated. The article frames the issue as tooling and process maturity, but the deeper shift is that deployment pipelines now decide who can change infrastructure, when they can do it, and with what privilege. That makes the pipeline a governance boundary, not just an engineering workflow. Practitioners should treat every IaC control as an access control.

Secrets-in-code is the oldest NHI failure pattern in modern IaC. Hardcoded keys, static environment variables, and repository-stored credentials turn infrastructure code into a credential distribution channel. That is not a theoretical weakness, it is a lifecycle failure where the secret outlives the trust context in which it was created. The implication is that NHI governance must be designed around runtime issuance and revocation, not around code hygiene alone.

Policy-as-code only works when the policy matches the real identity boundary. Blocking unsafe network exposure or enforcing encryption is useful, but it does not solve entitlement sprawl if the modules themselves carry excessive IAM roles or hidden trust relationships. In other words, the control plane can be automated while the identity model remains manual. Practitioners should audit whether policy checks govern the actual blast radius or only the visible syntax.

Identity blast radius is the right concept for modern IaC. Reusable modules, GitOps, and automated approvals reduce friction, but they also make one mis-scoped identity choice repeat everywhere faster. That changes the security question from “can we deploy safely?” to “how far does a single entitlement mistake propagate?” The practitioner conclusion is to measure privilege propagation, not just deployment velocity.

AI-assisted IaC raises the bar for review because speed now increases the chance of confidently wrong infrastructure changes. The article correctly points toward AI-readiness, but the governance challenge is not AI as such. It is that generated code can scale misconfiguration faster than human review cycles can absorb it. Practitioners should assume that generation speed magnifies both good and bad patterns unless policy and test gates are equally automated.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• The The 52 NHI breaches Report shows how compromised credentials repeatedly turn governance gaps into breach paths.

What this signals

Identity blast radius is the metric IaC teams should start watching. When modules, pipelines, and policy engines all touch privileged cloud actions, a single entitlement error can propagate faster than manual review can contain it. That is why programme owners should map where IAM roles, secrets, and approval steps are actually enforced, not just documented.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, the maturity gap is structural rather than incidental. If your IaC programme still depends on human discipline to keep credentials out of code, automation will simply scale the exposure.

The next governance step is to align pipeline controls with lifecycle controls for non-human identities. That means revocation, rotation, and drift response need to operate as one process, because IaC failure is usually an identity failure expressed through infrastructure.

For practitioners

• Separate credential storage from infrastructure code Move all cloud keys, tokens, and database credentials into a dedicated secrets manager or secret agent, and inject them only at runtime. Do not allow secrets in repositories, Terraform variables, or console-visible environment variables.
• Treat shared IaC modules as governed identity assets Apply ownership, code review, and version pinning to modules that contain IAM roles, network controls, or policy logic. A single module defect can replicate across many accounts, so module approval should be stricter than ordinary application code.
• Move access checks into pipeline enforcement Use policy-as-code to block non-compliant changes before apply, including overly permissive IAM roles, public exposure paths, and unapproved resource types. Make the pipeline the default approval point rather than a post-deployment audit.
• Measure drift as an identity signal Track console changes, out-of-band privilege grants, and manual edits as indicators that identity governance has slipped outside the IaC control loop. If drift appears frequently, the real issue is usually approval bypass or weak ownership, not just tooling noise.

Key takeaways

• Modern IaC turns cloud change into an identity governance problem because pipelines now mediate privileged access at scale.
• Unsafe secrets handling remains a persistent NHI weakness, with hardcoded credentials and delayed revocation creating durable exposure.
• Practitioners need pipeline-enforced policy, governed modules, and runtime secrets handling to keep automation from widening blast radius.

Key terms

• Infrastructure as Code: Infrastructure as code is the practice of defining cloud resources in version-controlled files so they can be reviewed, tested, and deployed consistently. In security terms, it becomes an identity control surface because those files often determine who can create, modify, or delete privileged infrastructure.
• Policy as Code: Policy as code is the encoding of security and governance rules in machine-readable logic that can be enforced automatically. It moves decisions about access, exposure, and compliance into the deployment pipeline, which reduces manual review gaps but also requires precise rule design.
• Drift Detection: Drift detection compares deployed infrastructure with the approved code definition to find out-of-band changes. In identity governance, it is useful because it can reveal manual privilege changes, console edits, or emergency exceptions that bypass the normal approval path.
• Secrets Manager: A secrets manager is a controlled service for storing, issuing, and rotating credentials such as keys, tokens, and certificates. It reduces the risk of hardcoded secrets by separating credential lifecycle management from application code and infrastructure templates.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by ControlMonkey: IaC modernization sits at the core of scalable, secure, and resilient cloud operations. Read the original.