Secure and consistent deployment

Exam tasks: 6.2 (skills 6.2.1 IaC across accounts with StackSets, Guard and cfn-lint, 6.2.2 tagging, 6.2.3 central policy with Firewall Manager, 6.2.4 sharing with Service Catalog and AWS RAM)

The decision: where in the path from a developer's commit to a running resource should each security check sit, and which central service pushes the same secure baseline into every account without someone doing it by hand?

Checks along the deployment pathCopy Anchor Link

Hardening CloudFormation templatesCopy Anchor Link

Keep secrets out of templatesCopy Anchor Link

• Dynamic references pull values at deploy time, so the template never contains them:
  • {{resolve:secretsmanager:prod/orders/db:SecretString:password}} for a Secrets Manager secret.
  • {{resolve:ssm-secure:/prod/orders/api-key}} for an SSM SecureString (only supported on some resource properties).
  • {{resolve:ssm:/golden/ami-id}} for a plain parameter.
• Better still, let the service own the secret. RDS and Aurora can create and rotate the master password in Secrets Manager themselves (ManageMasterUserPassword), so nobody ever sees it.
• NoEcho: true on a parameter masks it as asterisks in describe calls and the console. It doesn't mask a value you copy into Outputs, the Metadata section or a resource's own configuration, such as a Lambda environment variable anyone with lambda:GetFunctionConfiguration can read.

Protect the stack itselfCopy Anchor Link

• A service role is how you give a team "deploy through CloudFormation only". Their own role has no EC2 or IAM write permissions, and an SCP or permissions boundary stops them passing a more powerful role.
• Restrict which roles can be passed with iam:PassRole scoped to specific role ARNs and the iam:PassedToService condition set to cloudformation.amazonaws.com.

Policy as codeCopy Anchor Link

CloudFormation GuardCopy Anchor Link

• Open-source policy-as-code tool with a declarative DSL. It validates CloudFormation and Terraform plan JSON, Kubernetes manifests and other JSON or YAML against your rules.
• Run cfn-guard validate in the pipeline. The Guard rules registry has ready-made rule sets mapped to common frameworks.
• The same rule language runs in three places: the pipeline, Guard Hooks in CloudFormation, and AWS Config custom policy rules. Write once, check at every stage.

CloudFormation HooksCopy Anchor Link

• Run inside CloudFormation before a resource, stack or change set operation (and for Cloud Control API operations). Implement them with Guard rules, a Lambda function, or a custom Hook from the registry.
• Each Hook has a failure mode: FAIL blocks the operation, WARN lets it continue and records the result. Start with WARN to measure impact, then switch to FAIL.
• Control Tower proactive controls are pre-built Hooks that you enable on OUs instead of writing your own.

Drift detectionCopy Anchor Link

• Drift is any difference between a stack's template and the live resources: a security group rule added in the console, a bucket policy loosened by hand, a resource deleted outside CloudFormation.
• Run drift detection on a stack, a single resource, or a whole StackSet. It reports each resource as in sync, modified, deleted or not checked, with a property-level diff.
• Drift detection doesn't run continuously on its own. Use the Config managed rule cloudformation-stack-drift-detection-check to evaluate stacks on a schedule and alert through EventBridge.
• To fix drift, update the stack so the template wins again, or update the template to match reality and import the resource. Then remove the permission that let someone change it by hand.

Deploying across accounts with StackSetsCopy Anchor Link

• Use service-managed StackSets for security baselines: Config rules, IAM roles for incident response, GuardDuty export settings, the KMS key and vault that a backup policy needs.
• Service-managed StackSets don't deploy to the management account, even if you target the root. Deploy there separately if you need to.
• Control failure tolerance and concurrency so a bad template stops after a few accounts, not all of them.

Sharing approved resourcesCopy Anchor Link

AWS Service CatalogCopy Anchor Link

• Portfolios of products (CloudFormation templates or Terraform configurations) that users can launch without having permissions for the underlying services.
• A launch constraint names the IAM role Service Catalog uses to provision the product. The end user only needs Service Catalog permissions, which is how you let developers create a compliant, encrypted database without giving them rds:*.
• Template constraints limit parameter values (only these instance types). TagOptions apply mandatory tags.
• Share portfolios across the organization or to specific OUs from the management account or a delegated admin. Imported portfolios keep the admin's products and constraints.

AWS Resource Access ManagerCopy Anchor Link

• Shares resources (subnets, Transit Gateways, Route 53 Resolver rules, Network Firewall policies, License Manager configurations and more) with other accounts, OUs or the whole organization. The owner keeps control.
• Enable sharing with AWS Organizations so shares inside the org apply without invitations.
• Block sharing outside the organization with an SCP that denies ram:CreateResourceShare and ram:UpdateResourceShare when ram:RequestedAllowsExternalPrincipals is true.
• Managed permissions define what consumers can do with a shared resource. Use customer managed permissions for least privilege.

Firewall ManagerCopy Anchor Link

Firewall Manager pushes network and edge security policies to every in-scope account and resource from one administrator account, and reapplies them when new accounts or resources appear.

• Prerequisites: Organizations with all features, a Firewall Manager administrator account (you can have several, each scoped to OUs, accounts, Regions or policy types), and AWS Config enabled in every account and Region in scope.
• Scope each policy by account, OU and resource tags. Choose auto remediate to fix non-compliant resources, or report only.
• Firewall Manager is regional for most policy types. Create the policy in each Region you use (and in us-east-1 for CloudFront).

Tagging strategyCopy Anchor Link

• Decide a small set of mandatory tags up front, for example owner, cost-center, environment and data-classification. Keep keys lowercase and values from a fixed list.
• Tags drive security, not just billing: ABAC conditions (aws:ResourceTag, aws:PrincipalTag), Firewall Manager scope, Config rule scope, Backup plan selection, and Security Hub CSPM finding context.
• Enforcement stack:
  • Tag policy for allowed keys, case and values.
  • SCP denying create calls without the required tag (aws:RequestTag), and denying tag changes on security-relevant tags except by an admin role (aws:TagKeys).
  • Config managed rule required-tags to find what slipped through.
  • Service Catalog TagOptions and CloudFormation stack-level tags so approved paths tag automatically.
• Use Resource Groups and Tag Editor to find and fix resources in bulk.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Security best practices for CloudFormation
• What are CloudFormation Hooks?
• StackSets with service-managed permissions
• Using AWS Firewall Manager policies