O que encontrei,
o que fiz.

Recebi uma base de módulos herdada de um ambiente corporativo. Logo na primeira olhada apareceram senhas em texto puro, access keys fixas nos pipelines, módulos sem versão e até um que nunca tinha funcionado. Antes de criar qualquer coisa nova, eu precisava entender o que tinha nas mãos.

Comecei auditando os 41 módulos, um por um, e organizei o trabalho em 4 ondas: limpar, proteger, versionar e padronizar. Para provar que funcionava de verdade, criei um app piloto e fiz o primeiro deploy. Nada passou de primeira: o GitHub não achava o workflow, a AWS recusava o login, o scanner barrava a imagem. Cada erro virou um ajuste no módulo, não um remendo no projeto.

Hoje, um push na branch certa coloca o site no ar em menos de 2 minutos, sem nenhuma senha guardada no GitHub. Se alguém tentar publicar pela branch errada, a própria AWS recusa. E a imagem da API saiu de 26 vulnerabilidades para zero.

Descobri na prática que ser administrador da AWS não é ser administrador do Kubernetes: o console mostrava "Unauthorized" nos nós. Eles também subiam sem nome, sem tags e com disco sem criptografia. E um ambiente de estudo ligado o tempo todo custava caro.

Criei uma role de administrador do cluster, com o mínimo de permissão, que só quem é autorizado consegue assumir, em vez de liberar usuário por usuário. Os nós passaram a usar um launch template com IMDSv2 obrigatório, disco gp3 criptografado, Amazon Linux 2023 e tags padronizadas. Para o custo: um único NAT no ambiente de estudo e o hábito de destruir tudo com um checklist no final.

Cerca de 70 recursos criados em uns 14 minutos e destruídos sem sobrar nada cobrando. O acesso ficou rastreável por role, e os nós saem padronizados e protegidos desde o primeiro boot.

Com várias APIs e quatro ambientes, deploy feito direto do pipeline com kubectl deixa o cluster sem histórico claro: ninguém sabe ao certo o que está rodando, rollback é manual e o pipeline precisa de credencial de administrador do cluster. No Argo CD, cada aplicação nova ainda entrava aplicando a Application à mão, e algumas configurações sensíveis viajavam junto dos manifests.

Separei o caminho em dois. O GitHub Actions testa, faz o build, passa a imagem no Trivy, publica no ECR (login por OIDC) e atualiza a tag no kustomization.yaml do ambiente, num repositório GitOps. O Argo CD, instalado como código, observa esse repositório e aplica no EKS. Automatizei o onboarding com app of apps e ApplicationSet: aplicação nova é uma pasta no Git, sem passo manual. E tirei as credenciais dos manifests: cada aplicação tem o seu ServiceAccount com IRSA e recebe da AWS uma credencial temporária só com as permissões dela.

Tudo que roda no cluster está descrito no Git: cada deploy é um commit, com autor e data, e rollback é um git revert. Aplicação nova entra no cluster com um merge, sem nenhum passo manual no Argo CD, e nenhuma credencial fica no Git ou nos manifests. O pipeline não tem acesso ao cluster, e o Argo CD corrige sozinho qualquer mudança feita na mão (testado: apaguei um Deployment e ele voltou em segundos). Com o metrics-server como add-on, a API escala de 2 para 4 pods sozinha.

Um banco provisionado fica ligado com o mesmo tamanho o dia inteiro, mesmo quando quase ninguém está usando. A conta vem cheia nas horas paradas, e aguentar um pico exige planejar capacidade com antecedência.

Levei o banco para o Aurora PostgreSQL Serverless v2. A capacidade é medida em ACUs e a AWS ajusta sozinha, em segundos, entre um mínimo e um máximo que eu defino. A senha do administrador fica gerenciada pela AWS no Secrets Manager, a conexão exige SSL e tudo está descrito em Terraform.

O custo passa a acompanhar o uso real, sem pagar por capacidade parada, e o banco acompanha a demanda sem ninguém precisar mexer. Backups, atualizações e alta disponibilidade ficam com a AWS, e o time foca na aplicação.

Cada repositório tinha o seu próprio pipeline, copiado e colado de outro. Corrigir um problema significava abrir o mesmo PR em vários lugares, e com o tempo cada cópia ia ficando diferente da outra.

Juntei os passos comuns (build, testes, segurança e deploy) em workflows reutilizáveis num repositório central. Cada projeto chama com poucas linhas e escolhe a versão pela tag, seguindo SemVer: mudança que quebra compatibilidade vira versão major. Tudo é configurável por inputs e não tem segredo no código, porque o acesso à AWS é por OIDC.

Um ajuste no pipeline é feito uma vez só e chega aos projetos quando eles sobem de versão, no tempo de cada um. Um app novo ganha CI e deploy completos com um arquivo curto. Este próprio site usa esse modelo.

O pipeline entrava na AWS por OIDC, sem nenhuma chave guardada. Um dia começou a dar AccessDenied. A role confiava num formato de identificação do repositório, mas o token passou a chegar com o ID numérico da organização e do repositório junto do nome.

Fui ao CloudTrail, encontrei o evento AssumeRoleWithWebIdentity e comparei o que tinha chegado com o que a role esperava. Ajustei o módulo de OIDC para montar a condição no formato novo, com validação por regex, e publiquei como uma nova versão do módulo.

O deploy voltou a funcionar e ficou mais seguro: o ID não muda se alguém renomear ou recriar um repositório com o mesmo nome, então ninguém consegue herdar a permissão por engano. A trava de branch continua: deploy pela branch errada, a AWS recusa.

O Trivy roda no pipeline e barra vulnerabilidades HIGH e CRITICAL. Ele reprovou a imagem da API, mas os problemas nem eram do código da aplicação: vinham do npm que já vem dentro da imagem base e de bibliotecas do sistema desatualizadas. E a versão do Node usada já tinha chegado ao fim do suporte.

Reescrevi o Dockerfile em multi-stage: uma etapa para preparar e outra, enxuta, só com o que é preciso para rodar. Na imagem final removi npm, yarn e corepack, que a aplicação não usa em produção, atualizei os pacotes do sistema e subi para o Node 22.

A imagem saiu de 26 vulnerabilidades para zero e ficou mais enxuta. O scanner continua ligado e barrando: segurança virou parte do caminho, não uma etapa opcional.