Acesso humano entre contas AWS com Permission Sets

Seu time precisa acessar uma segunda conta AWS. O caminho curto costuma ser criar outro usuário IAM, gerar uma access key e guardar o segredo em ~/.aws/credentials — ou naquele cofre cujo nome já virou sinônimo de “depois a gente organiza”. Funciona, mas deixa uma credencial de longa duração espalhada e multiplica identidades que precisam ser revogadas separadamente.

Para pessoas, o caminho recomendado é federação com credenciais temporárias. Com o AWS IAM Identity Center, você associa um grupo a um Permission Set em cada conta. A pessoa autentica uma vez, escolhe a conta e recebe uma sessão limitada. Ao final, vamos validar duas coisas: a identidade ativa é um role AWSReservedSSO_* e a access key antiga já não funciona.

O exemplo usa uma instância organizacional do IAM Identity Center e AWS CLI v2. Os IDs de conta, instância, Permission Set e grupo são ilustrativos; não execute os comandos administrativos em produção sem revisão e controle de mudança.

O que muda em relação ao usuário IAM

Um usuário IAM e sua access key pertencem a uma conta. A chave é uma credencial de longa duração: continua válida até ser desativada ou excluída. Já o IAM Identity Center centraliza a identidade humana e entrega credenciais temporárias para a combinação:

• grupo ou usuário;
• Permission Set;
• conta AWS de destino.

A própria documentação de boas práticas do IAM recomenda que pessoas usem federação e credenciais temporárias. O Permission Set é o modelo de permissões: pode reunir políticas gerenciadas pela AWS, políticas gerenciadas pelo cliente, política inline e, quando necessário, permissions boundary.

A sessão do Permission Set dura uma hora por padrão e pode ser configurada até 12 horas. Isso não é o mesmo que a sessão do portal de acesso, cujo prazo é configurado separadamente. A credencial usada pela CLI ainda expira mesmo que o portal continue aberto.

O ganho operacional aparece na revogação. Em vez de procurar chaves AKIA... em notebooks, variáveis de ambiente e perfis antigos, você remove a atribuição do grupo à conta. Para observar a mudança com segurança, consulte os eventos do Identity Center e de login no CloudTrail e confirme as atribuições no portal. A auditoria passa a responder “qual grupo recebeu qual Permission Set em qual conta”, em vez de “quem será que ainda usa esta chave?”.

Isso vale para acesso humano. Workloads de CI têm outro fluxo: OIDC, roles e políticas próprias. Se esse for o seu caso, veja GitHub Actions na AWS com OIDC. SSO humano e identidade de workload resolvem problemas vizinhos, não intercambiáveis.

Permission Set provisiona o role: você não cria um concorrente

Não há uma escolha operacional entre criar manualmente um role IAM e criar um Permission Set para o mesmo fluxo. Para acesso multi-account, o Identity Center usa o Permission Set como modelo e provisiona em cada conta atribuída um role controlado pelo serviço:

AWSReservedSSO_<nome-do-permission-set>_<sufixo-unico>

Fora de us-east-1, o ARN inclui a região da instância do Identity Center:

arn:aws:iam::<conta>:role/aws-reserved/sso.amazonaws.com/<regiao>/AWSReservedSSO_<nome>_<sufixo>

Quando a instância fica em us-east-1, o segmento de região é omitido. Você não edita a trust policy desse role para adicionar usuários IAM, serviços ou outros principals. O Identity Center é proprietário do role e somente identidades atribuídas por ele entram nesse caminho.

ABAC também é uma configuração separada. Atributos de usuário podem virar session tags e participar das políticas do Permission Set ou dos recursos, mas aws:PrincipalTag e aws:RequestTag não são o mecanismo padrão de confiança do role reservado.

O fluxo completo é:

1. Uma instância organizacional habilita acesso multi-account na organização AWS.
2. O administrador cria o Permission Set.
3. Um grupo recebe esse Permission Set em uma conta de destino.
4. O Identity Center cria e mantém o role AWSReservedSSO_* na conta.
5. A pessoa escolhe conta e role pelo portal ou pela CLI e recebe credenciais temporárias.

Uma instância por conta não substitui esse pré-requisito: ela não concede acesso a contas AWS. Para verificar o provisionamento sem alterar nada, abra a conta de destino no IAM e procure o role sob o caminho /aws-reserved/sso.amazonaws.com/. Confira também a atribuição no console do Identity Center.

Há uma armadilha importante: ao remover todas as atribuições de um Permission Set em uma conta, o role reservado é excluído. Se ele for recriado, o sufixo muda. Recursos como uma key policy do KMS ou configurações antigas do EKS que fixaram o ARN completo deixam de reconhecer o role. Quando uma integração precisar referenciá-lo, siga o padrão com ArnLike documentado pela AWS e preserve ao menos uma atribuição administrativa enquanto fizer a transição.

Definindo Permission Set e atribuição como código

O CloudFormation oferece os recursos AWS::SSO::PermissionSet e AWS::SSO::Assignment. Este recorte cria um Permission Set somente leitura com sessão de oito horas e o associa a um grupo. Novamente: os identificadores são exemplos.

Resources:
  PermissionSet:
    Type: AWS::SSO::PermissionSet
    Properties:
      InstanceArn: arn:aws:sso:::instance/ssoins-instanceId
      Name: WorkloadDev
      SessionDuration: PT8H
      ManagedPolicies:
        - arn:aws:iam::aws:policy/ReadOnlyAccess

  Assignment:
    Type: AWS::SSO::Assignment
    Properties:
      InstanceArn: arn:aws:sso:::instance/ssoins-instanceId
      PermissionSetArn: !GetAtt PermissionSet.PermissionSetArn
      TargetId: "123456789011"
      TargetType: AWS_ACCOUNT
      PrincipalType: GROUP
      PrincipalId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

As referências oficiais de Permission Set e Assignment descrevem as propriedades aceitas. Prefira grupos a atribuições individuais: entrada e saída de pessoas ficam no provedor de identidade, enquanto o acesso à conta continua versionado no template.

Se você estiver validando o fluxo pela CLI administrativa, os comandos equivalentes começam assim:

aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx \
  --name WorkloadDev \
  --session-duration PT8H

aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx \
  --target-id 123456789011 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx \
  --principal-type GROUP \
  --principal-id aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

A criação da atribuição é assíncrona. Consulte describe-account-assignment-creation-status com o request ID retornado antes de testar o acesso; repetir o login enquanto o provisionamento ainda corre só transforma propagação em investigação criminal. Alterações posteriores nas políticas do Permission Set precisam ser provisionadas novamente nas contas atribuídas com provision-permission-set.

Em produção, observe esses eventos no CloudTrail, mantenha o template e a revisão que aprovou a mudança, e evite alterações paralelas pelo console. Para atribuir acesso à management account da organização, revise também as permissões administrativas adicionais exigidas; contas membro não têm exatamente o mesmo requisito.

Configurando o perfil SSO na AWS CLI v2

Use o formato com uma seção sso-session, que permite renovação do token, em vez do perfil SSO legado. A configuração abaixo vai em ~/.aws/config:

[profile workload-dev]
sso_session = company-sso
sso_account_id = 123456789011
sso_role_name = WorkloadDev
region = us-east-1

[sso-session company-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

O valor de sso_role_name é o nome apresentado no portal, isto é, o nome do Permission Set. A conta deve ser a conta de destino, não a conta de management por conveniência.

Você pode gerar essa configuração de modo guiado:

aws configure sso

A AWS CLI v2 usa PKCE por padrão desde a versão 2.22.0. Quando o navegador estiver em outro dispositivo, use aws configure sso --use-device-code. Depois, autentique e verifique a identidade:

aws sso login --profile workload-dev
aws sts get-caller-identity --profile workload-dev

GetCallerIdentity não exige permissão IAM específica. Uma resposta esperada tem a forma:

{
  "UserId": "AROAxxxxxxxx:session-name",
  "Account": "123456789011",
  "Arn": "arn:aws:sts::123456789011:assumed-role/AWSReservedSSO_WorkloadDev_<suffix>/<session-name>"
}

Três sinais importam:

• Account é a conta de destino;
• Arn contém assumed-role/AWSReservedSSO_;
• UserId tem o identificador do role seguido do nome da sessão, e não começa como um usuário IAM AIDA....

Por baixo do comando, a CLI autentica por OIDC no portal do Identity Center, obtém o token e solicita credenciais temporárias para aquela conta e Permission Set. A pessoa não usa uma access key estática para executar manualmente sts assume-role.

Se o resultado ainda mostrar arn:aws:iam::...:user/..., pare antes de concluir a migração. Execute:

aws configure list --profile workload-dev

A origem das credenciais não deve aparecer como shared-credentials-file apontando para uma access key. Variáveis AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN também podem ganhar precedência sobre o perfil esperado. Remova-as do shell e repita o login e o get-caller-identity:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
aws sso login --profile workload-dev
aws sts get-caller-identity --profile workload-dev

O cache do SSO fica em ~/.aws/sso/cache; ele guarda material temporário, não transforma a sessão em uma nova chave permanente. Para encerrar as sessões locais armazenadas pela CLI:

aws sso logout

Provando que a chave antiga saiu do caminho

Uma resposta positiva do SSO prova que o fluxo novo funciona, mas não prova que o antigo morreu. Faça o recuo de forma controlada:

1. Confirme com o responsável que nenhum workload depende da chave humana.
2. Desative a access key do usuário IAM legado.
3. Teste o perfil SSO e confirme o ARN AWSReservedSSO_*.
4. Teste separadamente um perfil que contenha somente a chave desativada.
5. Após a janela de observação e o plano de rollback acordado, exclua a chave e, se não houver outra dependência, o usuário IAM.

Não misture os dois perfis no teste. Caso contrário, a cadeia de credenciais pode encontrar uma chave estática e você acaba validando o passado com muita convicção.

Para uma chave excluída, uma chamada S3 pela CLI deve falhar com InvalidAccessKeyId:

AWS_PROFILE=legacy-human aws s3 ls

Uma chamada ao STS pode retornar UnrecognizedClientException:

AWS_PROFILE=legacy-human aws sts get-caller-identity

InvalidClientTokenId é uma mensagem genérica de token inválido e não deve ser usada como prova específica de que uma access key foi excluída. ExpiredTokenException, por sua vez, aponta para uma sessão temporária expirada, não para a remoção da chave IAM.

O roteiro de observação fica compacto:

Quando adotar este desenho

Para pessoas que acessam uma ou mais contas de uma organização AWS, adote uma instância organizacional do IAM Identity Center, atribuições por grupo e Permission Sets versionados. Mantenha access keys de longa duração apenas para exceções documentadas em ferramentas que realmente não suportem credenciais temporárias — e trate a exceção como dívida com responsável e prazo.

O próximo passo é pequeno: escolha um grupo e uma conta não produtiva, crie um Permission Set somente leitura, faça o login pela AWS CLI v2 e salve a saída de get-caller-identity como evidência da migração. Só depois desative a chave antiga em uma janela controlada e confirme no CloudTrail que o caminho federado continua sendo usado.