Creating a BigBang member account is only half the job. Once the account exists, something has to deploy applications into it without handing out account-wide admin rights. This Terraform module owns the IAM side of every BigBang-generated account: it is meant to be the single place where all identity and access for those accounts is defined. Today it provisions one thing well, the deployer role used to ship containerized apps to ECS, and it is built to grow into the home for any future IAM needs of BigBang accounts.

What it provisions

• The deployer role: an IAM role that can deploy an ECS application end to end, including the ECS service, the task and execution roles the app needs, load balancer listener rules, target groups, security groups, Route53 records, and the usual supporting resources (CloudWatch Logs, ECR, Application Auto Scaling, ACM read, read-only SSM Parameter Store and Secrets Manager, and Cloud Map).
• A permissions boundary: required on every role the deployer creates, capping any created role to the same envelope as the deployer itself so it cannot be used to escalate privileges or change the network.

The role deliberately cannot create IAM users or groups, and cannot create or modify networking resources such as VPCs, subnets, route tables, gateways, peering, or VPC endpoints. Security groups are the one network-adjacent exception, since apps need them.

Why a boundary and a path

The deployer has to be able to create roles, since ECS task and execution roles are created per app. A simple deny list would be bypassable, so the module combines two controls. First, the permissions boundary above is mandatory on every role the deployer creates. Second, all role and instance-profile actions are confined to a dedicated IAM path (/deployer/ by default), so the deployer cannot rewrite the trust of, or delete, privileged roles that live outside that path, such as OrganizationAccountAccessRole or the reserved SSO roles.

Who can assume it

The deployer role trusts exactly two kinds of principal: SSO administrators in the same account (the reserved AdministratorAccess SSO role), and the bitbucket-openid OIDC role in the main account, which already grants pipelines the right to assume deployer in every account. The module reads no remote state; the caller passes in values such as the main account id.

How it is consumed

As a Terraform module it declares no backend and no provider; the consuming account-configuration project supplies them. The deployer role holds no S3 or state permissions, so it is not self-sufficient for a full run: the AWS provider assumes this member-account deployer role to manage application resources, while the Terraform backend assumes the main-account deployer role that holds the state bucket permissions.

Repository: bitbucket.org/arglabs/arglabs-tfmod-bigbang-iam