Terraform pela esteira: ninguém mais roda apply do PC
Validação em todo PR, plan comentado sem chave nenhuma, apply em dois botões e um EKS criado pela esteira com uma role sem AdministratorAccess.
william@devops:~$ ls ./blog
BLOG TÉCNICO
Artigos sobre Cloud, Kubernetes, CI/CD e segurança, escritos a partir do que deu certo e do que deu errado no trabalho.
Validação em todo PR, plan comentado sem chave nenhuma, apply em dois botões e um EKS criado pela esteira com uma role sem AdministratorAccess.
Aplicação nova entrando no cluster com um merge, e cada app com seu ServiceAccount e sua role na AWS. Nenhuma credencial nos manifests.
Seis apps no Argo CD, a API escalando de 2 para 4 pods sozinha e um Deployment apagado na mão que voltou em segundos.
Subi um EKS, instalei o Argo CD por Terraform e vi a API entrar no ar sozinha, lida do Git. Com os prints reais e as partes em que eu travei.
AccessDenied sem ninguém mexer na role. O CloudTrail mostrou o culpado: o GitHub passou a mandar o ID junto com o nome do repositório.
O Trivy barrou a imagem da API. O problema estava na imagem base. Como cheguei a zero sem desligar o scanner.
Senha em texto puro, módulo que nunca rodou e versão bagunçada. Como dei nota para cada um e arrumei tudo em quatro ondas.
Como estava quando cheguei, como organizei as branches, como tirei as chaves da AWS do pipeline e o que fiz para ninguém parar de entregar no meio da troca.
A chave fixa guardada no GitHub virou uma credencial que dura minutos. Conto como fechei a trust policy e deixei cada role só com o que precisa.
Por que mexer só no cluster não bastou: o código também precisou mudar. O passo a passo até apagar as chaves sem derrubar nenhuma aplicação.
Como organizei versões e branches entre desenvolvimento, homologação, staging e produção, e os tropeços que tive até o Git virar a fonte da verdade.