Perfis AWS em toolkits: descubra com list-profiles e valide com STS

Toolkits de cloud costumam começar simples: ler ~/.aws/config, extrair alguns nomes e montar um menu.

Funciona até aparecerem perfis com source_profile, credenciais em mecanismos diferentes ou uma configuração que não combina com o parser improvisado.

No meu toolkit, a abordagem consolidada ficou mais simples: deixar a própria AWS CLI dizer quais perfis ela conhece.

1

aws configure list-profiles

Depois, a identidade efetiva é validada com STS dentro da sessão correspondente.

1

aws sts get-caller-identity

O artigo original desta pauta dizia que os perfis existiam, STS funcionava e “a ferramenta não os encontrava”. A fonte recuperada comprova a implementação robusta atual, mas não reconstrói com segurança aquele defeito anterior. Por isso reduzi o título ao comportamento que consigo provar.

Não parseie configuração se a CLI já tem uma API para isso #

Um seletor de perfil pode ser tão simples quanto:

1
2
3

aws configure list-profiles 2>/dev/null \
  | sort -u \
  | fzf --prompt='AWS Profile > '

Isso evita tentar interpretar manualmente seções como:

1
2
3

[profile producao]
region = us-east-1
source_profile = base

ou diferenças entre ~/.aws/config e ~/.aws/credentials.

A AWS CLI já resolve a visão de perfis que ela própria utiliza.

Primeiro valide se o perfil existe #

No toolkit, uma função auxiliar verifica a lista conhecida antes de aceitar um argumento fornecido pelo operador.

Conceitualmente:

1
2
3
4
5

aws-profile-exists() {
  local wanted="$1"
  aws configure list-profiles \
    | grep -Fxq -- "$wanted"
}

Se o argumento não for válido, o fluxo volta para seleção interativa.

Isso é melhor do que deixar o erro aparecer muito depois em um comando destrutivo ou demorado.

Perfil e identidade são coisas diferentes #

O nome do perfil não prova qual conta/role foi assumida.

A verificação real é:

1

aws sts get-caller-identity

No meu fluxo com aws-vault, a validação é executada dentro da sessão temporária:

1
2

aws-vault exec "$profile" -- \
  aws sts get-caller-identity --output table

Assim eu consigo conferir:

1
2
3

Account
Arn
UserId

antes de operar recursos.

Em ambiente com várias contas, essa checagem é barata comparada ao custo de executar o comando certo na conta errada.

Region também precisa ser resolvida de forma previsível #

O toolkit recupera a region configurada para o perfil e mantém um fallback operacional quando ela não existe.

Uma leitura simples:

1

aws configure get region --profile "$profile"

Se a ferramenta precisa fixar uma region:

1

aws configure set region us-east-1 --profile "$profile"

Mas isso já é uma alteração de configuração; não deve acontecer silenciosamente só porque o perfil foi selecionado.

Seleção, validação e mudança devem ser ações distintas.

source_profile merece atenção #

Um perfil pode depender de outro:

1
2
3

[profile app-prod]
source_profile = base
role_arn = arn:aws:iam::000000000000:role/Example

O toolkit consulta:

1

aws configure get source_profile --profile "$profile"

Em um fluxo específico de configuração de region, ele pode alinhar a region do perfil e do source_profile quando isso é deliberadamente desejado.

O ponto é saber que existe essa relação, em vez de tratar cada seção como credencial independente.

aws-vault resolve credencial temporária; não identidade conceitual #

Abrir console ou shell com:

1

aws-vault login "$profile"

ou:

1

aws-vault exec "$profile" -- bash

é conveniente.

Mas continuo usando STS para confirmar a identidade efetiva.

O fluxo fica:

1
2
3
4
5

selecionar profile
→ resolver region
→ criar sessão aws-vault
→ sts get-caller-identity
→ operar

Isso reduz a dependência de memória do operador sobre qual nome corresponde a qual conta.

Um menu não deve esconder a CLI real #

No toolkit, fzf é apenas uma camada de ergonomia.

A fonte de perfis continua sendo:

1

aws configure list-profiles

A identidade continua sendo:

1

aws sts get-caller-identity

E o mecanismo de sessão continua sendo aws-vault.

Se o menu quebrar, os comandos de base permanecem reproduzíveis no terminal.

Essa propriedade é importante em ferramenta de plantão.

Evite armazenar Account IDs no código para descobrir quem é quem #

É possível criar um mapa rígido:

1
2

profileA → conta X
profileB → conta Y

Mas isso envelhece e pode vazar informação desnecessária.

Para operação, prefiro descobrir a identidade em runtime com STS e, quando necessário, manter aliases humanos em configuração privada separada.

No artigo, nenhum Account ID real precisa ser publicado.

Um seletor robusto #

Exemplo reduzido:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

pick_aws_profile() {
  local profile

  profile="$(
    aws configure list-profiles 2>/dev/null \
      | sort -u \
      | fzf --height=45% --layout=reverse \
            --prompt='AWS Profile > '
  )" || return 1

  [[ -n "$profile" ]] || return 1
  printf '%s\n' "$profile"
}

Validação:

1
2
3
4

profile="$(pick_aws_profile)" || exit 1

aws-vault exec "$profile" -- \
  aws sts get-caller-identity --output table

O que a fonte prova #

O script recuperado comprova um toolkit próprio com:

• descoberta por aws configure list-profiles;
• ordenação e escolha via fzf;
• verificação explícita de existência de perfil;
• suporte a argumento ou escolha interativa;
• aws-vault login e aws-vault exec;
• validação por aws sts get-caller-identity;
• leitura/configuração de region;
• tratamento de source_profile;
• limpeza de sessões aws-vault.

Ele não é usado para afirmar qual era exatamente o bug histórico que motivou a pauta original.

Checklist #

1
2
3
4
5
6
7
8

[ ] perfis vêm de aws configure list-profiles
[ ] seleção não depende de parser caseiro
[ ] argumento é validado antes de usar
[ ] region é lida explicitamente
[ ] source_profile é conhecido quando existe
[ ] sessão temporária usa mecanismo controlado
[ ] sts get-caller-identity confirma conta/role
[ ] IDs reais não ficam hardcoded no conteúdo público

O principal aprendizado #

Um perfil chamado prod é só um nome.

A operação segura começa quando a ferramenta consegue responder duas perguntas sem adivinhação:

quais perfis a AWS CLI realmente conhece?

qual identidade esse perfil assumiu agora?