Isso foi feito em produção, numa empresa em que trabalhei. Os exemplos usam nomes genéricos, sem nenhum dado da empresa.
01 / PONTO DE PARTIDA
O Argo CD estava lá. A automação, ainda não.
O GitOps funcionava para quem já estava dentro: as aplicações existentes sincronizavam com o Git. O gargalo era entrar. Cada aplicação nova pedia um passo manual no Argo CD, e quem fazia precisava lembrar de todos os detalhes.
Onboarding manual
Cada aplicação nova dependia de aplicar a Application à mão. Esquecer um campo era descobrir só no deploy.
Configuração sensível nos manifests
Algumas credenciais de acesso à AWS viajavam junto do deployment, em vez de vir de uma identidade própria.
Argo CD sem código
Mudança na instalação era feita direto no cluster. Recriar o ambiente era lembrar de cada passo.
Permissão compartilhada
Sem identidade por aplicação, fica difícil dar a cada uma só o acesso que ela precisa.
02 / ONBOARDING PELO GIT
Aplicação nova virou uma pasta.
App of apps + ApplicationSet
Uma Application raiz aponta para a pasta do cluster no repositório GitOps. Dentro dela, um ApplicationSet cria um app para cada pasta em apps/. Para colocar uma aplicação nova, o time cria a pasta com os manifests e abre um PR. Depois do merge, o Argo CD faz o resto.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: apps-dev
namespace: argocd
spec:
generators:
- git:
repoURL: git@github.com:minha-org/gitops.git
revision: develop
directories:
- path: apps/* # uma pasta = um app
template:
metadata:
name: "{{ .path.basename }}-dev"
spec:
project: apps
source:
path: "{{ .path.path }}/overlays/dev"
destination:
namespace: "{{ .path.basename }}-dev"
syncPolicy:
automated:
prune: true # o que sai do Git sai do cluster
selfHeal: true # mudança feita na mão é desfeitaProjetos que limitam o alcance
As aplicações ficam num projeto do Argo CD que só lê o repositório GitOps e só cria recursos nos namespaces delas. Um manifest errado não atinge o resto do cluster.
03 / ARGO CD COMO CÓDIGO
A própria instalação passou a ter histórico.
O Argo CD, os projetos e a Application raiz passaram a ser instalados por código, com versão fixa do chart. Atualizar o Argo CD virou um PR revisado, e recriar o ambiente do zero deixou de depender da memória de alguém.
04 / IDENTIDADE POR APP
Cada aplicação com o seu crachá.
Em vez de credenciais junto do deployment, cada aplicação ganhou um ServiceAccount próprio, ligado a uma role da AWS só dela, com IRSA. O pod recebe um token do cluster, a AWS confere de qual ServiceAccount ele veio e entrega uma credencial temporária com as permissões daquela aplicação, e de mais nenhuma.
apiVersion: v1
kind: ServiceAccount
metadata:
name: api-pagamentos
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<conta>:role/dev-api-pagamentos-irsaDo lado da AWS, a role só aceita o token daquele ServiceAccount, naquele namespace:
condition {
test = "StringEquals"
variable = "${local.oidc_host}:sub"
values = ["system:serviceaccount:pagamentos-dev:api-pagamentos"]
}No deployment, sobra só o nome do ServiceAccount. Nenhuma chave no manifest, nenhum secret para rotacionar, e cada chamada aparece no CloudTrail com a role da aplicação que fez.
05 / RESULTADO
Menos passos, menos risco.
Onboarding com um merge aplicação nova entra no cluster sem nenhum passo manual no Argo CD.
Nenhuma credencial nos manifests cada app usa a identidade do seu ServiceAccount, com credencial temporária.
Permissão mínima por aplicação uma role por app, só com o que ela precisa.
Tudo rastreável cada mudança é um commit e cada acesso à AWS aparece no CloudTrail com o nome da role.
Ambiente reproduzível o Argo CD e os projetos sobem por código, com versão fixa.
06 / APRENDIZADOS
O que eu levo dessa.
GitOps de verdade não é ter o Argo CD instalado: é ninguém precisar entrar nele para colocar uma aplicação no ar. E segurança boa é a que vem por padrão. Quando cada aplicação nasce com a sua identidade, ninguém precisa lembrar de proteger nada depois.
william@devops:~$ echo $LESSON_LEARNED
"Se para colocar um app no ar alguém precisa entrar no Argo CD, ainda não é GitOps."