TFMOD: BigBang IAM

Criar uma conta membro do BigBang é só metade do trabalho. Depois que a conta existe, algo precisa fazer o deploy das aplicações nela sem usar o acesso de administrador da conta. Este módulo Terraform entrega isso: a role deployer que os pipelines assumem em toda conta BigBang.

O que ele provisiona

A role deployer, com uma única política inline:

• Permitido: tudo o que uma aplicação do ARGLabs ou a plataforma BigBang precisam colocar no ar. Isso é ECS, ECR, EC2 (incluindo security groups), load balancers e autoscaling, Lambda, EventBridge e seu Scheduler, API Gateway, SQS, SNS, RDS, ElastiCache, EFS, S3 com Glue e Athena, CloudFront e WAF, ACM, Route 53, Cloud Map, CloudWatch e seus logs, SSM, Secrets Manager, KMS e Resource Explorer.
• IAM: criar, alterar e excluir roles, instance profiles e políticas gerenciadas, e passar roles para serviços, porque cada aplicação cria suas próprias roles de task e de execução. Não tem nenhuma ação sobre usuários ou grupos IAM, então não pode criá-los.
• Negado: toda ação que cria ou altera a rede: VPCs, sub-redes, route tables e rotas, internet, egress-only, NAT, VPN e transit gateways, peering, network ACLs, DHCP options e VPC endpoints. A rede pertence à conta Shared Network. Os security groups continuam permitidos, já que os apps precisam deles, assim como o único VPC endpoint que o ElastiCache Serverless cria para si.

Quem pode assumi-la

A role deployer confia em exatamente dois principals: os administradores SSO da mesma conta (a role SSO reservada AdministratorAccess) e a role OIDC bitbucket-openid da Main Account, que pode assumir deployer em todas as contas. O módulo não lê nenhum remote state; quem o chama passa valores como o id da Main Account.

O trade-off: sem permissions boundary

Uma role que pode criar roles pode criar uma mais poderosa que ela mesma. A proteção usual combina dois controles: uma permissions boundary que toda role criada por ela deve ter anexada, limitando essa role às permissões do próprio criador, e um path IAM (como /deployer/) fora do qual o criador não pode mexer em roles, para que não consiga reescrever a confiança de uma role privilegiada como a OrganizationAccountAccessRole.

As versões anteriores deste módulo tinham os dois. Foram removidos porque os módulos de aplicação criam suas roles de execução e de task sem path e sem boundary. Então, hoje, os bloqueios de rede (denies) valem para o próprio deployer, mas não para uma role que ele cria. Fechar essa brecha significa trazer de volta a boundary e o path, neste módulo e em todo módulo que cria uma role.

Como ele é consumido

Como módulo Terraform, ele não declara backend nem provider: o arglabs-tfmod-bigbang o chama a partir da configuração de conta de cada escopo. A role não tem permissões de S3 e não precisa delas. O provider AWS assume o deployer da conta membro para gerenciar recursos, enquanto o backend do Terraform lê e grava o state na Main Account com a role OIDC do pipeline, sem assumir nenhuma role.

Repositório: bitbucket.org/arglabs/arglabs-tfmod-bigbang-iam