Infrastructure as code security
Review infrastructure definitions, rendered plans, deployment authority, sensitive state, and runtime drift as parts of one controlled change workflow.
What it means
Infrastructure as code expresses infrastructure configuration in versioned definitions. This supports repeatability and review, but an insecure definition can reproduce an exposure across environments. Security controls must cover development, deployment authority, stored state, and changes made outside the declared configuration.
A practical example
A storage deployment is reviewed for public access, encryption, and service identity permissions before being applied. The team also protects the state file because it can contain sensitive values and detects manual changes that create drift from reviewed configuration.
What to check
Review templates, modules, state storage, and deployment credentials. Test policy rules against the rendered plan and monitor runtime drift rather than assuming a reviewed template guarantees current settings.
A common pitfall
Keeping infrastructure definitions in Git does not automatically protect secret values or prevent unauthorized manual changes. The deployed state remains the final security concern.
Think it through
Why review state storage separately from source templates?
Answer: State may contain sensitive resource details or secrets that require stronger access control than the template itself.
Source review is an important beginning
Imagine a fictional academy creates storage and application infrastructure from versioned definitions. A reviewer can inspect the intended public-access settings and identity permissions before deployment. That is useful, but the deployed resources remain the operational result to verify.
Variables, modules, provider behavior, and environment-specific values influence the rendered plan. Review the resolved change rather than assuming a safe-looking template produces the same resources everywhere.
Deployment credentials can change the boundary
Suppose the automation identity can edit every account policy even though the current template only creates one storage resource. A compromised pipeline could use authority beyond the reviewed change. Scope the deployer's effective permissions to the environment and task.
State storage and plan artifacts also need protection. They can contain sensitive infrastructure details or values. Keeping source code private does not automatically protect artifacts copied elsewhere in the workflow.
Drift separates intention from current reality
An administrator might make a manual emergency change after the reviewed deployment. The repository then describes an older state. Detect and reconcile drift through an agreed process rather than treating version control as proof that production still matches the code.
For the academy, a temporary public-storage exception should have an owner and removal condition. The next deployment's effect on that manual change must be understood before applying it blindly.
For a safe exercise, write a fictional storage plan with private access and a narrowly scoped workload identity. Describe the checks before deployment and the observations after deployment. Then introduce an invented manual permission change and explain how the team detects and resolves the discrepancy. The workflow should preserve reviewability, protect sensitive artifacts, and verify actual exposure instead of equating automation with automatic security.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Infrastructure as Code Security