Este estudo apresenta uma experiência profissional real de forma anonimizada. Nomes de empresas, contas, domínios, repositórios e detalhes sensíveis foram omitidos.
01 / CONTEXTO
O pipeline precisava acessar a AWS. A access key não precisava morar nele.
Pipelines de CI/CD precisam publicar imagens, consultar recursos e atualizar componentes da plataforma. Em muitos ambientes, esse acesso começa com uma chave IAM armazenada como secret. A solução funciona, mas cria uma credencial persistente que precisa ser distribuída, rotacionada e protegida.
A modernização adotou identidade federada com OpenID Connect. Em vez de guardar uma credencial AWS no GitHub, cada workflow comprova sua identidade durante a execução e solicita uma sessão temporária para uma role específica.
PRINCÍPIO DO PROJETOA automação deve provar quem é antes de receber somente o acesso de que precisa.
02 / RISCO
O problema não era apenas guardar o segredo. Era controlar o alcance dele.
Uma credencial de longa duração pode permanecer válida fora do pipeline e ser reutilizada caso seja exposta. Além disso, uma mesma chave compartilhada por diferentes repositórios ou ambientes dificulta saber qual automação realizou cada ação.
Persistência
Chaves continuam válidas até serem revogadas ou rotacionadas.
Abrangência
Permissões compartilhadas tendem a crescer além da necessidade real.
Rastreabilidade
Uma identidade comum reduz a clareza sobre a origem de cada ação.
Operação
Rotação e distribuição de secrets criam trabalho recorrente e risco de falha.
03 / ARQUITETURA
Confiança baseada no contexto da execução.
O GitHub emite um token OIDC com informações verificáveis sobre a execução, como repositório, branch e ambiente. O AWS Security Token Service valida essas informações contra a trust policy da role e, quando as condições são atendidas, entrega credenciais temporárias ao workflow.
AUTENTICAÇÃOO token identifica o contexto real do workflow.
AUTORIZAÇÃOA role define quais ações aquele contexto pode executar.
EXPIRAÇÃOA sessão termina automaticamente após um período curto.
04 / DECISÕES TÉCNICAS
A segurança está nas condições, não apenas no uso do OIDC.
Trust policy restrita ao repositório e à referência correta
As relações de confiança foram limitadas aos repositórios autorizados e ao contexto esperado de branch ou ambiente. Isso impede que qualquer workflow da organização assuma a role somente por usar o mesmo provedor.
audience: sts.amazonaws.com
subject:
repository: brown-cloud/lab-test
reference: environment:production
session:
duration: short_livedname: publish-lab-test
on:
push:
branches: [main]
permissions:
contents: read
id-token: write
jobs:
publish:
runs-on: ubuntu-latest
environment: production
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Assume AWS role with OIDC
uses: aws-actions/configure-aws-credentials@v6.2.3
with:
role-to-assume: ${{ vars.AWS_DEPLOY_ROLE }}
aws-region: ${{ vars.AWS_REGION }}
- name: Publish immutable image
run: ./scripts/publish-image.sh lab-test ${{ github.sha }}Roles separadas por ambiente e finalidade
Desenvolvimento, homologação e produção receberam fronteiras claras. Uma automação responsável por publicar imagens não precisa da mesma role que atualiza um repositório GitOps ou executa uma operação administrativa.
Políticas construídas pelo menor privilégio
Cada role recebeu somente as ações e recursos necessários. Permissões genéricas foram evitadas, e o escopo foi revisado a partir do que o workflow realmente executava.
- Acesso limitado aos recursos relacionados à aplicação.
- Separação entre leitura, publicação e ações de operação.
- Produção condicionada ao fluxo de aprovação definido.
Migração sem fallback permanente para chaves estáticas
Depois da validação do OIDC, os secrets antigos foram removidos do fluxo. Manter a chave como alternativa indefinida preservaria o mesmo risco que o projeto pretendia eliminar.
05 / EXECUÇÃO
A mudança foi tratada como uma evolução de segurança e operação.
- 01
Inventário
Mapeamento dos pipelines, credenciais existentes, ações AWS e ambientes envolvidos.
- 02
Fundação
Configuração do provedor OIDC e criação das roles com relações de confiança controladas.
- 03
Piloto
Validação com uma aplicação representativa e análise do fluxo completo de publicação.
- 04
Expansão
Replicação do padrão com policies específicas para os demais repositórios e contextos.
- 05
Desativação
Remoção das access keys antigas e confirmação da rastreabilidade das novas sessões.
06 / RESULTADOS
Menos segredos para administrar, mais contexto para controlar.
Os resultados são apresentados de forma qualitativa, sem atribuir percentuais que não foram medidos publicamente.
Credenciais temporárias geradas somente quando um workflow autorizado é executado.
Menor superfície de exposição com a retirada de access keys armazenadas no CI/CD.
Separação entre ambientes por meio de roles e condições de confiança específicas.
Melhor rastreabilidade das sessões assumidas e das ações realizadas na AWS.
Governança mais clara para integrar novos repositórios ao padrão de segurança.
07 / APRENDIZADOS
OIDC não é apenas uma troca de credencial. É um novo modelo de confiança.
O ganho real aparece quando identidade, contexto e permissão são avaliados em conjunto. Configurar o provedor é apenas o começo; a qualidade da solução depende das condições da trust policy, da separação das roles e da remoção efetiva das credenciais antigas.
Quando bem aplicado, o modelo reduz tarefas operacionais e torna a segurança parte natural do fluxo de entrega, sem exigir que os times manipulem segredos de longa duração.
william@devops:~$ echo $LESSON_LEARNED
"Automação segura não carrega uma identidade permanente: ela recebe confiança somente pelo tempo e contexto necessários."