7.2.1. Infrastructure as Code Security
First Principle: Infrastructure as code makes security repeatable and auditable — but only if the templates themselves are validated for security compliance before deployment.
AWS CloudFormation Security:
- StackSets: Deploy templates across multiple accounts and Regions simultaneously
- CloudFormation Guard: Rule-based policy-as-code tool that validates templates before deployment
- cfn-lint: Linter that checks CloudFormation templates for errors and best practices
- Drift detection: Identifies resources that have changed from their template-defined configuration
CloudFormation Guard Example:
Guard rules enforce security requirements in templates:
- "All S3 buckets must have encryption enabled"
- "No security group may allow ingress from 0.0.0.0/0 on port 22"
- "All RDS instances must have MultiAZ enabled"
Secure IaC Pipeline:
Third-Party IaC Tools:
- Terraform, Pulumi, CDK — all can be validated with pre-deployment security scanning
- AWS supports these tools through CloudFormation Registry custom resources
- The security principle is the same: validate before deploy, monitor for drift after
⚠️ Exam Trap: CloudFormation Guard validates templates BEFORE deployment (preventive). Config drift detection identifies changes AFTER deployment (detective). Both are needed — Guard prevents, Config detects.
Scenario: A StackSet deploys a standardized VPC template with security groups, NACLs, and VPC endpoints to all new accounts. CloudFormation Guard validates the template before deployment, and Config monitors for post-deployment drift.
Reflection Question: Why does a secure IaC pipeline need both pre-deployment validation (Guard) and post-deployment monitoring (Config drift)?
