15.1 Infrastructure as Code Security & Multi-Account Deployment

15.1 Infrastructure as Code Security & Multi-Account Deployment

Modern cloud security requires treating infrastructure definitions with the same rigor, version control, and automated validation applied to mission-critical application software. Managing cloud infrastructure through manual console interactions ("ClickOps") introduces configuration drift, human error, unrecorded modifications, and compliance blind spots. Infrastructure as Code (IaC) establishes a declarative, auditable source of truth where security controls, network perimeters, encryption standards, and least-privilege policies are defined in version-controlled templates.

However, authoring IaC templates does not automatically guarantee security. Misconfigurations defined in templates—such as open security groups, unencrypted EBS volumes, or publicly accessible S3 buckets—can be replicated instantly across hundreds of accounts when automated deployment pipelines execute. To protect enterprise cloud estates, security engineers must enforce a shift-left security paradigm: embedding automated syntactic analysis, domain-specific policy evaluation, and deployment-time safeguards directly into developer workflows and continuous integration/continuous deployment (CI/CD) pipelines.

---

AWS CloudFormation StackSets Architecture

While AWS CloudFormation manages resources within a single AWS account and Region, AWS CloudFormation StackSets extends this functionality across multiple accounts and multiple Regions using a single CloudFormation template. A StackSet acts as a central management blueprint that creates, updates, and deletes individual Stack Instances across specified target accounts and Regions.

StackSet Hierarchy:
[StackSet Definition (Template + Parameters)]
       │
       ├── Stack Instance (Account A, us-east-1) ──> CloudFormation Stack
       ├── Stack Instance (Account A, us-west-2) ──> CloudFormation Stack
       ├── Stack Instance (Account B, us-east-1) ──> CloudFormation Stack
       └── Stack Instance (Account B, us-west-2) ──> CloudFormation Stack

Security Baseline Deployment Use Cases

Security teams rely heavily on StackSets to provision uniform governance baselines across enterprise landing zones, including:

• Centralized IAM Roles: Deploying break-glass incident response roles, security auditor cross-account roles, and third-party monitoring roles with standardized trust policies.
• Detective Service Enrollment: Enabling and configuring Amazon GuardDuty, AWS Security Hub, Amazon Macie, and AWS Config across all active Regions.
• Network & Cryptographic Baselines: Locking down default VPC security groups to deny all ingress and egress traffic, enabling account-level EBS default encryption with Customer Managed Keys (CMKs), and enabling S3 Block Public Access at the account level.
• Operational Guardrails: Distributing automated incident response AWS Lambda functions, Amazon EventBridge rules, and Systems Manager (SSM) association documents.

---

Service-Managed vs. Self-Managed Permissions

When creating a StackSet, administrators must choose between two permission models that dictate how CloudFormation authenticates and executes operations in target accounts.

Automatic Deployments with Service-Managed StackSets

A critical capability evaluated on the Specialty exam is lifecycle governance for new accounts. When organizations adopt AWS Control Tower or custom vending machines, new AWS accounts are continuously provisioned into specific OUs (e.g., Workloads-Prod, Sandbox).

With AutoDeployment enabled on a service-managed StackSet:

AutoDeployment:
  Enabled: true
  RetainStacksOnAccountRemoval: false

Whenever a new member account is created or moved into the target OU, CloudFormation automatically creates the corresponding stack instances in all specified Regions without administrative intervention. Conversely, if an account is detached or moved out of the OU, setting RetainStacksOnAccountRemoval: false ensures that proprietary corporate baseline stacks (such as internal security agents or VPC peering connections) are automatically torn down.

Operational Concurrency & Failure Governance

Deploying security baselines across hundreds of accounts and multiple Regions simultaneously introduces operational risks if a template defect causes mass deployment failures. CloudFormation StackSets provides fine-grained execution controls:

• MaxConcurrentCount / MaxConcurrentPercentage: Caps the number of stack instances deployed simultaneously. Setting this to a controlled percentage (e.g., 10%) prevents API rate-limiting and reduces blast radius.
• FailureToleranceCount / FailureTolerancePercentage: Defines the threshold of failed stack instance deployments allowed before CloudFormation halts the entire operation. Setting a failure tolerance of 0 ensures that if a deployment fails in a single account, the operation halts immediately rather than propagating across the enterprise.
• RegionConcurrencyType: Configures whether regional deployments occur sequentially (SEQUENTIAL) or simultaneously (PARALLEL). For security baselines with cross-Region dependencies, sequential deployment ensures regional stability.

---

Drift Detection in CloudFormation & StackSets

Over time, out-of-band modifications made directly via the AWS Management Console, AWS CLI, or automated scripts can cause the actual configuration of a live AWS resource to diverge from its expected configuration defined in the CloudFormation template. This divergence is known as configuration drift.

Drift Detection Mechanics

1. Triggering Drift Detection: Drift detection can be initiated on an entire stack, a StackSet, or individual resources within a stack using the DetectStackDrift or DetectStackResourceDrift API operations.
2. Property Comparison: CloudFormation retrieves the expected resource property values from the template and queries the live resource state using read APIs (Describe* / Get*).
3. Drift Status Evaluation:
   • IN_SYNC: The live resource configuration matches the template definition.
   • MODIFIED: Specific resource properties differ from the template (e.g., a security group has an unexpected inbound CIDR rule added).
   • DELETED: The physical resource was deleted outside of CloudFormation.
   • NOT_CHECKED: The resource type does not support drift detection.

Critical Exam Traps Regarding Drift

Important Exam Rule: Drift detection is purely an informational and detective capability. CloudFormation does NOT automatically revert, remediate, or overwrite drifted resources upon detection. To restore drifted resources to their expected template state, an administrator must either update the stack with an updated template, execute an explicit stack update that forces property re-application, or manually revert the live resource in the console/CLI.

Policy-as-Code with CloudFormation Guard (cfn-guard)

AWS CloudFormation Guard (cfn-guard) is an open-source, general-purpose policy-as-code evaluation tool designed to validate structured JSON and YAML data against domain-specific security rules. While originally designed for AWS CloudFormation templates, Guard can also evaluate Terraform plan JSON files, Kubernetes manifests, and AWS Serverless Application Model (SAM) templates.

Guard uses a concise, expressive Domain-Specific Language (DSL) that allows security engineers to define declarative security invariants without writing complex general-purpose programming code in Python or Java.

Guard Rule Architecture & Syntax

A Guard rule file (.guard) consists of clauses that define resource type queries and property assertions:

# Enforce S3 Bucket Server-Side Encryption and Public Access Block
let s3_buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]

rule CHECK_S3_BUCKET_SECURITY when %s3_buckets !empty {
    %s3_buckets {
        Properties {
            # Assert Public Access Block configuration exists and blocks public ACLs/policies
            PublicAccessBlockConfiguration exists
            PublicAccessBlockConfiguration {
                BlockPublicAcls == true
                BlockPublicPolicy == true
                IgnorePublicAcls == true
                RestrictPublicBuckets == true
            }
            # Enforce SSE-KMS encryption with Customer Managed Key
            BucketEncryption exists
            BucketEncryption.ServerSideEncryptionConfiguration[*] {
                ServerSideEncryptionByDefault.SSEAlgorithm == 'aws:kms'
                ServerSideEncryptionByDefault.KMSMasterKeyId exists
            }
        }
    }
}

Key Guard Rule Concepts

• Variable Assignments (let): Bind filtered collections of resources to named identifiers (e.g., let ebs_volumes = Resources.*[ Type == 'AWS::EC2::Volume' ]).
• Rule Clauses: Named blocks (e.g., rule ENFORCE_IMDSV2) that evaluate whether specific assertions hold true.
• Conditional Execution (when): Evaluates rule clauses only when specific conditions are met (e.g., when %ebs_volumes !empty).
• Custom Error Messages: Custom strings appended with <<ErrorMessage>> that output clear guidance to developers when an assertion fails:

let launch_templates = Resources.*[ Type == 'AWS::EC2::LaunchTemplate' ]

rule ENFORCE_EC2_IMDSV2 when %launch_templates !empty {
    %launch_templates.Properties.LaunchTemplateData.MetadataOptions.HttpTokens == 'required'
    <<Launch templates must enforce IMDSv2 by setting HttpTokens to required to prevent SSRF credential theft.>>
}

cfn-guard validate exits with code 0 when all rules pass and a non-zero code (19) when a rule fails, which is what stops the pipeline stage.

Unit Testing Guard Rules

Guard includes built-in unit testing capabilities via the cfn-guard test command. Security teams maintain test suites containing pairs of positive (compliant) and negative (non-compliant) template snippets to prove that policy rules correctly flag security violations and avoid false positives before deploying rules to CI/CD pipelines.

---

Static Analysis with cfn-lint

While CloudFormation Guard evaluates organizational business logic and security policies, cfn-lint (AWS CloudFormation Linter) focuses on template correctness, syntax, and schema validity against the official AWS CloudFormation Resource Specification.

What cfn-lint Detects

• Schema Violations: Unrecognized property names, invalid resource types, and incorrect data types (e.g., supplying an integer where a string is required).
• Intrinsic Function Misuse: Invalid usage of Fn::GetAtt, Fn::Sub, Fn::Join, or Ref (e.g., referencing a resource attribute that does not exist in the AWS resource specification).
• Circular Dependencies: Scenarios where Resource A depends on Resource B while Resource B simultaneously depends on Resource A.
• Mutual Exclusivity Errors: Supplying two configuration properties that cannot coexist (e.g., configuring both KmsKeyId and conflicting encryption parameters on certain database resources).

Comparing cfn-lint and cfn-guard

---

Pre-Commit and CI/CD Security Gating Pipeline

To prevent security regressions and avoid deployment delays, security teams implement automated gating across three distinct lifecycle stages:

Developer Laptop (Pre-Commit) ──> CI/CD Pipeline (Build/Test) ──> CloudFormation Engine (Hooks)
[cfn-lint + git-secrets]          [cfn-guard validate]             [AWS CloudFormation Hooks]

1. Pre-Commit Hooks: Local workstation validation using tools like pre-commit.
   • Executes git-secrets or trufflehog to detect hardcoded AWS access keys or passwords before commits are recorded.
   • Executes cfn-lint for instantaneous developer feedback on template syntax.
2. CI/CD Pipeline Gating:
   • Pipeline runners (e.g., AWS CodePipeline, GitHub Actions) execute cfn-guard validate --rules <rules.guard> --data <template.yaml>.
   • If any rule evaluations fail, the runner exits with code 1 or 2, failing the build and blocking merge or deployment actions.
   • Change Sets are automatically generated via aws cloudformation create-change-set to allow security engineers to review exact resource additions, modifications, and replacements.
3. AWS CloudFormation Hooks:
   • CloudFormation Hooks represent an engine-level safeguard. Unlike pre-commit or CI/CD checks that rely on pipeline compliance, Hooks are registered directly within the CloudFormation registry in target AWS accounts.
   • Hooks proactively intercept stack operations (pre-create, pre-update, pre-delete).
   • If a template violates a registered hook rule (e.g., attempting to deploy an unencrypted S3 bucket directly via the console or CLI), the CloudFormation engine automatically fails the stack creation or update before any physical resources are provisioned.

---

Specialty Exam Pitfalls & Architectural Traps

1. The Drift Auto-Remediation Trap: Assuming CloudFormation drift detection automatically repairs drifted infrastructure. Drift detection only alerts and catalogs discrepancies; returning resources to compliance requires manual updates or re-running deployment automation.
2. Self-Managed StackSets Permission Misconfiguration: Forgetting that self-managed StackSets require the administration account to assume AWSCloudFormationStackSetExecutionRole in target accounts. If the trust policy does not explicitly permit the administration account's role (AWSCloudFormationStackSetAdministrationRole), stack instance operations fail with access denied errors.
3. Confusing Detective Config Rules with Preventive Guard Policies: Expecting AWS Config rules to block an insecure CloudFormation deployment. Config rules evaluate resources after they are provisioned (reactive/detective). To prevent insecure resources from ever being created, teams must use cfn-guard in pipelines or CloudFormation Hooks at deployment time.
4. Overlooking AutoDeployment Behavior on Account Removal: With automatic deployment enabled, RetainStacksOnAccountRemoval defaults to false, so moving an account out of a target OU deletes the stack instances and their resources, including security baselines. Set it to true when the baseline (for example, logging or guardrail resources) must survive an OU move.