IAM outbound federation passa a conectar partições AWS: Commercial, GovCloud, China e Europa

O problema das partições isoladas

AWS organiza suas regiões em partições: Commercial (a nuvem pública padrão, incluindo sa-east-1 em São Paulo), AWS GovCloud (US), China (operada por parceiros locais) e, mais recentemente, a European Sovereign Cloud. Cada partição tem sua própria instância de IAM, completamente isolada das demais. Uma credencial emitida numa role da GovCloud nunca funciona num sts:AssumeRole feito dentro da partição Commercial, e uma resource policy do Commercial não consegue referenciar um principal que existe só na GovCloud.

Para quem desenha arquitetura multi-partição (empresas com contrato federal americano, operação na China, ou filial europeia sob a nova nuvem soberana), essa barreira sempre forçou soluções manuais: credenciais de longo prazo copiadas entre contas, usuários IAM duplicados, ou processo fora de banda pra sincronizar acesso. Nenhuma dessas opções é compatível com encerrar automaticamente um acesso quando ele deixa de ser necessário.

Como funciona o outbound identity federation entre partições

O AWS Security Blog descreve a extensão do IAM outbound identity federation, recurso que já existia pra autenticar workloads em serviços externos via JWT assinado pela AWS, agora estendido pra assumir roles em outra partição AWS. O fluxo depende de duas chamadas:

1. O workload chama sts:GetWebIdentityToken na partição de origem e recebe um JWT de curta duração, assinado pela AWS, com claims como account ID, ARN do principal e região de origem.
2. O workload apresenta esse token pra sts:AssumeRoleWithWebIdentity no endpoint STS da partição de destino, junto com o ARN da role alvo.
3. O STS de destino busca a chave pública no endpoint JWKS do emissor OIDC, valida a assinatura, avalia a trust policy da role e devolve credenciais temporárias.

Não há credencial de longo prazo armazenada em nenhum ponto do processo. O exemplo do blog usa acesso a um bucket do Amazon S3: um workload rodando em us-gov-west-1 (GovCloud) obtém o token e troca por credenciais temporárias válidas em us-east-1 (Commercial) pra ler um objeto.

Configurando o fluxo na prática

O setup exige trabalho nas duas pontas. Na conta de origem, a federação é habilitada uma única vez por conta:

aws iam enable-outbound-web-identity-federation --region us-gov-west-1 --profile GovCloudCredentials

Esse comando devolve uma issuer URL única (algo como https://<unique-id>.tokens.sts.us-gov.api.aws), que funciona como endpoint de descoberta OIDC.

Na conta de destino, essa URL é registrada como provedor OIDC e vira a base de uma trust policy condicionada:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::<destination-account-id>:oidc-provider/<unique-id>.tokens.sts.us-gov.api.aws"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "<unique-id>.tokens.sts.us-gov.api.aws:sub": "arn:aws-us-gov:iam::<source-account-id>:role/<workload-role>",
      "<unique-id>.tokens.sts.us-gov.api.aws:aud": "<audience>",
      "<unique-id>.tokens.sts.us-gov.api.aws:source_region": "us-gov-west-1"
    }
  }
}

Repare que o controle de acesso aqui não é "qualquer token válido passa": a trust policy condiciona em sub (a role de origem exata), aud (audiência esperada) e source_region. Dá pra ir além e condicionar também em org_id, restringindo a federação a uma AWS Organization inteira.

Do lado da origem, a policy que libera sts:GetWebIdentityToken usa Resource: "*" porque essa API não tem recurso endereçável (ela não assume uma role específica, só emite o token). Isso só é aceitável porque o verdadeiro controle de menor privilégio fica nas condições: sts:IdentityTokenAudience fixa a audiência, sts:DurationSeconds limita a vida do token a 300 segundos, e sts:SigningAlgorithm força ES384. Sem essas condições, o * abriria emissão de token pra qualquer audiência, o que anula a utilidade da federação.

Rastreabilidade e revogação

Um ponto que interessa direto a quem faz pós-mortem ou responde incidente: os dois lados do fluxo aparecem no AWS CloudTrail. O evento GetWebIdentityToken na origem grava responseElements.webIdentityTokenId; o evento AssumeRoleWithWebIdentity no destino grava o mesmo valor em requestParameters.webIdentityTokenId, junto com o ARN do principal de origem e a região de origem. Cruzar esses dois campos reconstrói o caminho completo de um acesso entre partições, coisa que credencial de longo prazo compartilhada nunca deu de graça.

Também dá pra revogar credenciais já emitidas, escopando por origem ou aplicando um deny na role de destino. Isso importa porque, diferente de um sts:AssumeRole dentro da mesma partição, aqui a confiança atravessa um limite administrativo e regulatório, não só uma fronteira técnica.

O que muda pra quem opera multi-conta e multi-partição

Esse recurso resolve um problema bem específico, não genérico. Pra maioria dos arquitetos brasileiros operando só em sa-east-1 e demais regiões Commercial, nada muda no dia a dia. A federação entre partições importa pra quem está num destes cenários:

• Empresas brasileiras com contrato ou filial que exige presença na AWS GovCloud (contrato com agência federal americana, por exemplo).
• Multinacionais com operação na China, onde a partição é isolada por desenho.
• Grupos europeus (ou com filial europeia) migrando workloads pra European Sovereign Cloud, que precisam ocasionalmente ler ou escrever em recursos na partição Commercial.

Nesses casos, o ganho real é eliminar o padrão anterior de credencial de longo prazo copiada manualmente entre contas de partições diferentes, substituindo por um token que expira em até 300 segundos e carrega identidade de origem auditável. É o mesmo raciocínio por trás de federação OIDC pra GitHub Actions ou EKS, só que atravessando uma fronteira que a AWS normalmente trata como intransponível.

O blog é direto num ponto que merece grifo: antes de implementar, o time de compliance precisa validar o desenho contra as obrigações regulatórias aplicáveis, como FedRAMP, ITAR, DoD CC SRG ou GDPR. Não é detalhe de rodapé. Mover dados ou abrir caminho de acesso entre uma partição soberana e a Commercial pode, dependendo do contrato e da legislação, ser proibido independentemente de o mecanismo técnico ser seguro. O mesmo cuidado vale, por analogia, pra arquitetura desenhada sob LGPD onde a residência de dados é cláusula contratual: a pergunta não é "o IAM permite?", é "o contrato e o regulador permitem?".

A recomendação da AWS de que o acesso seja sempre iniciado da partição mais restrita pra menos restrita (GovCloud para Commercial, nunca o contrário) também é uma decisão de modelagem de ameaça que vale registrar em qualquer ADR que documente esse desenho.

O que fica em aberto

O post não detalha custo do recurso (a chamada de GetWebIdentityToken e AssumeRoleWithWebIdentity segue o modelo de precificação padrão do STS, sem cobrança adicional mencionada na fonte) nem lista todos os pares de partições já suportados além do exemplo GovCloud-Commercial. Também não há indicação de particularidades pra regiões do Brasil além do papel padrão de sa-east-1 como parte da partição Commercial. Pra quem avalia adotar, o caminho indicado pelo próprio post é o walkthrough completo de "Getting started with outbound identity federation" antes de desenhar a trust policy de produção.

Fonte: AWS Security Blog