Argo CD v3.5.4: checklist de segurança e planejamento do upgrade

Atualizar o Argo CD exige cuidado especial: estamos alterando a plataforma que entrega mudanças aos demais ambientes. A versão v3.5.4, publicada em 6 de outubro de 2026, inclui oito correções de segurança, quatro classificadas como críticas. Portanto, não se trata de uma única vulnerabilidade nem apenas de manutenção rotineira. (github.com)

Este roteiro propõe uma decisão operacional: identificar exposição, selecionar uma versão corrigida, testar os fluxos relevantes e executar uma mudança rastreável. Os exemplos são didáticos; nomes, topologia e critérios de aceite precisam ser adaptados antes de produção.

1. O que foi corrigido e por que importa

Os advisories abaixo foram publicados em 7 de outubro de 2026. Use o identificador GHSA para rastrear cada problema; não atribua um CVE inexistente ou confunda vulnerabilidades de releases anteriores com este conjunto. (github.com)

Não considere acesso de leitura automaticamente seguro

Na falha de referências Kustomize, a geração server-side de arquivos enviados pela API exige apenas get em uma Application existente. Escrita em Git e permissão de sync não são obrigatórias nesse caminho. Além disso, bloquear egress não impede a exploração por transporte local file://. A recomendação é atualizar, não considerar NetworkPolicy uma correção equivalente. (github.com)

No caso Jsonnet, a mesma superfície de upload pode alcançar uma Application de diretório. Isso justifica incluir consumidores de diff, integrações e usuários de leitura no inventário de exposição, não apenas administradores. (github.com)

Aprofundamento: referências remotas do Kustomize (GHSA-9v9p-x54c-58gc)

O advisory, publicado em 7 de outubro de 2026, abrange versões sem correção desde a 2.7.0; não lista patch para a v2. A entrada pode ocorrer por Git ou por POST /api/v1/applications/manifestsWithFiles, com apenas permissão get na Application. O transporte file:// dispensa egress, e os comandos podem acessar credenciais do processo. (github.com)

Atualizar somente o Kustomize não resolve. Fixar todas as execuções na 4.5.7 é uma mitigação limitada e incompatível com funcionalidades 5.x; manter caminhos 5.x disponíveis deixa a exposição. A solução completa indicada é atualizar o Argo CD. Não classifique uma instância como segura apenas porque os repositórios conhecidos parecem confiáveis: inclua usuários, automações e permissões de leitura no levantamento. (github.com)

O que muda com a correção? O problema envolve argumentos de git fetch: valores de ref ou version podiam ser interpretados como opções. O patch coloca um wrapper de Git no PATH da renderização, insere --end-of-options e protege também referências transitivas. Bases remotas legítimas continuam disponíveis; formatos inesperados de fetch são recusados. (github.com)

Não confunda a versão do Argo CD com a do Kustomize: spec.source.kustomize.version seleciona uma ferramenta registrada e não atualiza o controlador. (argo-cd.readthedocs.io)

2. Qual versão escolher

Os advisories listam 3.3.15, 3.4.10 e 3.5.4 como releases estáveis corrigidas, além de 3.6.0-rc2, que é uma pré-release. As faixas vulneráveis anteriores variam por problema; consulte cada advisory para instalações antigas. Não use a ausência de patch em uma linha antiga como evidência de ausência de vulnerabilidade. (github.com)

Minha recomendação de planejamento:

• Instalação 3.5.x: avaliar a atualização para 3.5.4.
• Instalação 3.4.x ou 3.3.x: considerar primeiro o patch corrigido da própria linha, evitando misturar resposta de segurança com migração funcional.
• Linha antiga: elaborar uma migração para uma linha suportada, lendo todos os guias intermediários.
• Pré-release: não adotar uma release candidate em produção apenas porque seu número é maior.

A política do projeto mantém correções nas três versões minor mais recentes. Valide novamente suporte e advisories ao executar a mudança: este artigo é um roteiro para a release indicada, não uma recomendação permanente de versão. (github.com)

3. Arquitetura: onde estão as fronteiras de confiança

Argo CD implementa entrega contínua declarativa para Kubernetes. O argocd-server expõe API e interface; o repo-server obtém fontes e gera manifestos; o application-controller compara o estado desejado com o cluster e executa a reconciliação. O fluxo simplificado é:

Git ou registry → repo-server → application-controller → API Kubernetes

Usuário ou automação → argocd-server → operações autorizadas

Esses componentes têm responsabilidades e superfícies de acesso diferentes. (argo-cd.readthedocs.io)

Uma Application define uma entrega; um AppProject restringe, entre outros elementos, fontes, destinos e tipos de recursos. Essas políticas complementam o controle de acesso baseado em funções, ou RBAC, mas não substituem as permissões Kubernetes das credenciais utilizadas pelo controller. (argo-cd.readthedocs.io)

A falha de hooks é especialmente relevante para multitenancy: o impacto fica limitado pelas credenciais do controller no cluster de destino, não pela intenção original do AppProject vulnerável. (github.com)

4. Checklist de inventário e exposição

Crie um registro por instalação, com responsável, ambiente, versão, origem do artefato e decisão de tratamento. Sugestão de checklist:

• [ ] Identificar contexto Kubernetes e namespace corretos.
• [ ] Registrar imagens desejadas e imageID dos containers em execução.
• [ ] Identificar o proprietário da instalação: Helm, Kustomize, manifests ou operador.
• [ ] Mapear Applications, AppProjects, ApplicationSets e clusters de destino.
• [ ] Inventariar renderizadores, plugins e imagens customizadas.
• [ ] Registrar quem pode alterar repositórios, templates de credenciais e políticas.
• [ ] Identificar acesso externo à API, contas locais e integrações de leitura.
• [ ] Atribuir responsável e prazo a cada instalação afetada.

Comandos de inspeção Kubernetes para começar, ajustando o namespace e verificando o contexto antes de qualquer alteração: (kubernetes.io)

kubectl config current-context
kubectl -n argocd get deployments,statefulsets,pods
kubectl -n argocd get pods \
  -o custom-columns='POD:.metadata.name,IMAGES:.spec.containers[*].image,IMAGE_IDS:.status.containerStatuses[*].imageID'
kubectl -n argocd get applications.argoproj.io
kubectl -n argocd get appprojects.argoproj.io
kubectl -n argocd get applicationsets.argoproj.io

Para a triagem específica, transforme os advisories em perguntas: existe --enable-helm? Há Jsonnet? Quem configura proxies SSH? Proxy extensions e Applications em outros namespaces estão habilitados simultaneamente? Os registries OCI são controlados? Registre evidência, não apenas respostas informais. (github.com)

Revise também kustomize.path.*, opções de build e seleções de versão por Application. Registre os Config Management Plugins (CMPs) como caminho de execução separado, com testes próprios; não presuma que um plugin customizado recebe automaticamente a proteção do fluxo nativo. (argo-cd.readthedocs.io)

Como triagem local das referências Kustomize, procure nos arquivos versionados:

git grep -nE 'https?://|ssh://|git@|file://|[?&](ref|version)=' \
  -- '*kustomization.yaml' '*kustomization.yml' '*Kustomization'

A busca é uma heurística, não uma prova de ausência de vulnerabilidade. Use-a para montar a matriz de testes, revisar dependências e encontrar pontos que precisam de análise manual.

5. Contenção temporária não é remediação completa

Se a atualização não puder ocorrer imediatamente, proponho uma mudança emergencial separada, com validade curta e aprovação de segurança.

Remover --enable-helm elimina o caminho descrito no advisory de configHome, mas pode interromper Applications que dependem dessa integração. Essa medida não corrige as outras vulnerabilidades. (github.com)

Para login local, desabilitar contas locais e utilizar autenticação centralizada pode reduzir a superfície correspondente. Essa falha não se aplica aos logins por Single Sign-On, ou SSO, e OpenID Connect, ou OIDC. (github.com)

Como recomendação de resposta a incidente, se houver indício de execução inesperada ou exposição de arquivos, preserve evidências, investigue credenciais acessíveis ao processo e planeje sua rotação. Não trate a troca da imagem como prova de que acessos anteriores foram revogados.

6. Backup e critérios de aprovação

Antes da janela, defina quem pode interromper a mudança, quem autoriza recuperação e quais evidências serão exigidas para encerrá-la.

O Argo CD oferece exportação administrativa. Use uma CLI compatível com a instalação e confira o namespace: a documentação alerta que exportar do namespace errado pode não produzir uma falha explícita. (argo-cd.readthedocs.io)

umask 077
argocd admin export -n argocd > argocd-backup.yaml

Trate o arquivo como sensível. Minha recomendação é criptografá-lo imediatamente, restringir acesso e testar restauração em ambiente isolado. Guarde também valores Helm, overlays, certificados, configurações externas e referências de imagens. O teste deve comprovar que a plataforma pode ser reconstruída; a simples existência do arquivo não é um critério suficiente.

Não confunda recuperação do Argo CD com recuperação das aplicações. Inclua PostgreSQL, volumes e serviços externos em seus próprios procedimentos de backup e restauração.

Matriz mínima de testes proposta

7. Compatibilidade: um patch de segurança pode alterar comportamento

Duas alterações precisam entrar explicitamente nos testes:

1. Kustomize deixa de respeitar helmGlobals.configHome; builds dependentes de plugins registrados por esse diretório podem falhar.
2. Manifestos OCI maiores que 4 MiB passam a ser rejeitados. O limite é do documento de manifesto, não do tamanho descompactado do artefato. (github.com)

Se a mudança também atravessar de 3.4 para 3.5, examine separadamente a migração para Helm 4, extensões de interface, clientes gRPC e configuração TLS do repo-server. Não atribua automaticamente essas mudanças ao patch 3.5.4. (argo-cd.readthedocs.io)

8. Execução controlada da atualização

Preserve o mecanismo proprietário da instalação. Em Helm, revise versão do chart, imagens renderizadas e tratamento de definições de recursos customizados, ou CRDs. Em instalações por operador, utilize o caminho suportado pelo operador. Não sobreponha manifests upstream indiscriminadamente a recursos gerenciados por outra ferramenta.

Para instalações baseadas em manifests, o exemplo abaixo apenas baixa a variante de alta disponibilidade, ou HA, da release. Revise-a e incorpore seus overlays antes de aplicar. A release também fornece uma variante não HA. (github.com)

curl --fail --location \
  https://raw.githubusercontent.com/argoproj/argo-cd/v3.5.4/manifests/ha/install.yaml \
  --output argocd-v3.5.4-ha.yaml

No procedimento proposto, rendered-argocd.yaml é o resultado já revisado da sua configuração, não o arquivo upstream aplicado às cegas. Siga o guia de upgrade e examine conflitos de propriedade antes de considerar --force-conflicts. (argo-cd.readthedocs.io)

kubectl diff -n argocd --server-side -f rendered-argocd.yaml
kubectl apply -n argocd --server-side -f rendered-argocd.yaml

Execute essas etapas separadamente: o código de saída 1 de kubectl diff significa diferenças encontradas, não necessariamente erro. Não automatize aprovação apenas com base na ausência de falha do apply. (argo-cd.readthedocs.io)

Ordem de promoção recomendada: homologação representativa, instância canário e demais instalações em lotes. Evite dois controllers independentes gerenciando os mesmos recursos como estratégia improvisada de blue/green.

9. YAML de defesa em profundidade

O exemplo completo abaixo restringe o ingresso TCP na porta 8081 do repo-server aos pods do servidor e do application-controller no mesmo namespace. É um ponto de partida, não uma política universal nem uma correção dos advisories. NetworkPolicy exige implementação compatível no plugin de rede; permissões de múltiplas políticas são aditivas. (kubernetes.io)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: repo-server-restricted-ingress
  namespace: argocd
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: argocd-repo-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-server
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-application-controller
      ports:
        - protocol: TCP
          port: 8081

Adapte namespace, labels e consumidores reais. Inclua regras específicas para monitoramento quando necessário. A política não restringe egress nem valida identidade criptográfica. Uma regra existente mais permissiva pode manter acessos que você pretendia remover. Teste conectividade antes de promover. (kubernetes.io)

Complemente o desenho com Transport Layer Security, ou TLS, menor privilégio e revisão dos Secrets montados. Restrinja permissões Kubernetes dos controllers e acesso administrativo ao namespace. Não introduza credenciais hardcoded ou acessos amplos para contornar erros após o upgrade. (argo-cd.readthedocs.io)

10. Produção, capacidade e custos

Em desenvolvimento isolado, uma réplica e observabilidade simplificada podem ser suficientes para testes. Minha recomendação para produção é validar redundância por componente, distribuir pods entre domínios de falha e reservar capacidade para substituição durante rollout. O escalonamento do controller deve considerar seu modelo de sharding; não copie a política de réplicas do repo-server para todos os componentes. (argo-cd.readthedocs.io)

Defina requests com base em medições e limits compatíveis com renderizações reais. Requests influenciam agendamento; limites de memória podem resultar em encerramento do container, e limites de CPU podem causar throttling. Ausência de requests e limites arbitrariamente baixos são riscos distintos. (kubernetes.io)

Um PodDisruptionBudget, ou PDB, ajuda a controlar interrupções voluntárias, mas não garante disponibilidade durante falhas de zona nem governa diretamente o rolling update do Deployment. Combine-o com estratégia de rollout e capacidade suficiente. (kubernetes.io)

Para FinOps, proponho acompanhar custo por instância, capacidade ociosa, retenção de logs e tráfego de registries. Evite colocar toda a plataforma crítica em capacidade Spot sem tolerância testada a interrupções. Uma base On-Demand pode ser uma decisão conservadora, não uma obrigação universal. Reavalie o dimensionamento depois que os caches estabilizarem.

11. Observabilidade e validação pós-upgrade

Use Prometheus e Grafana para acompanhar argocd_app_info, argocd_app_reconcile e argocd_app_sync_total. Correlacione com disponibilidade da API, erros de renderização, CPU, memória, reinicializações e conectividade dos clusters. Configure alertas sobre desvio da linha de base, evitando um limiar universal para todas as instalações. (argo-cd.readthedocs.io)

Proponho centralizar logs em Loki ou solução equivalente, com controle de acesso e retenção definida. Correlacione aplicação, revisão Git e horário da mudança. Traces, quando instrumentados, são complementares; não devem ser requisito para detectar indisponibilidade básica.

Após autenticar a CLI, substitua o nome da aplicação canário:

argocd app get platform-canary --hard-refresh
argocd app wait platform-canary --sync --health --timeout 300

O primeiro comando solicita atualização incluindo o cache de manifestos; o segundo aguarda os estados indicados. Os 300 segundos são um timeout ilustrativo, não um objetivo de nível de serviço. Faça a sincronização autorizada conforme seu processo; app wait não inicia um sync. (argo-cd.readthedocs.io)

Application de validação de renderização

Uma atualização precisa comprovar o comportamento do plano de entrega, não apenas Pods Ready. O exemplo abaixo, hipotético (uma API de pagamentos com uma base compartilhada de segurança e overlays por ambiente), pressupõe que o projeto platform-validation, o namespace de destino e o acesso ao repositório já existam. A estrutura usa a API declarativa oficial. (argo-cd.readthedocs.io)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-render-validation
  namespace: argocd
spec:
  project: platform-validation
  source:
    repoURL: https://github.com/example-org/platform-config.git
    targetRevision: REPLACE_WITH_APPROVED_COMMIT_SHA
    path: apps/payments/overlays/staging
  destination:
    server: https://kubernetes.default.svc
    namespace: payments-validation
  syncPolicy:
    automated:
      enabled: false

Substitua repositório, SHA, caminho, projeto e namespace: o placeholder não identifica um commit real. A sincronização automática está desabilitada de propósito; use a Application para inspecionar a renderização antes de autorizar qualquer implantação. Restrinja no AppProject as origens, destinos e tipos de recurso necessários (o YAML não cria essas políticas) e não copie credenciais de produção para homologação.

Para a Application de teste, solicite um hard refresh, que atualiza também o cache de manifests, e analise condições, revisão resolvida e diff. Não execute refresh em massa como primeiro teste. (argo-cd.readthedocs.io)

argocd app get payments-render-validation --hard-refresh
kubectl -n argocd get application payments-render-validation -o yaml

Execute testes de regressão de segurança apenas em laboratório descartável, sem Secrets reais e sem conectividade com produção. Um caso legítimo renderizado com sucesso verifica compatibilidade; não prova, isoladamente, resistência à exploração.

12. Troubleshooting

Use os nomes reais dos pods. Os comandos abaixo ajudam a distinguir falha de agendamento, reinicialização e erro de execução. (kubernetes.io)

kubectl -n argocd get pods -o wide
kubectl -n argocd describe pod <pod>
kubectl -n argocd logs <pod> --all-containers=true --tail=200
kubectl -n argocd logs <pod> -c <container> --previous
kubectl -n argocd get events --sort-by=.metadata.creationTimestamp

• Renderização Helm falha → possível dependência de `configHome` → revisar configuração e logs → migrar para um fluxo compatível com a correção. Não restaure o comportamento vulnerável como solução permanente. (github.com)
• OCI é rejeitado → manifesto acima do novo limite → inspecionar o documento retornado pelo registry → corrigir publicação ou origem do artefato. Aumentar memória não remove essa validação. (github.com)
• Hooks falham após o upgrade → possível restrição antes contornada → comparar recurso e AppProject → ajustar o hook ou aprovar uma permissão mínima justificada. (github.com)
• Erro de autenticação em base Kustomize privada → credencial incompatível → comparar a identidade usada na origem e na base → ajustar para o acesso mínimo. (argo-cd.readthedocs.io)
• Fetch recusado pelo wrapper → invocação inesperada de ferramenta customizada → conferir versão e argumentos nos logs → corrigir a integração. Não remova a proteção. (github.com)
• OOMKilled ou timeout na renderização → concorrência e capacidade insuficientes → investigar memória, disco e builds simultâneos → ajustar recursos e `--parallelismlimit` antes de ampliar timeouts. (argo-cd.readthedocs.io)
• Application aparenta estado antigo → cache ainda não atualizado → conferir revisão e condições → usar hard refresh apenas no alvo investigado. (argo-cd.readthedocs.io)

• Pods em Pending ou reiniciando → capacidade, limites ou configuração → consultar eventos e término anterior → corrigir a causa identificada antes de prosseguir. (kubernetes.io)

13. Rollback sem normalizar o risco

Minha recomendação é preferir correção adiante quando a alternativa for reintroduzir uma vulnerabilidade crítica. Defina previamente gatilhos para parar a promoção: perda de acesso administrativo, falha generalizada de renderização ou alteração inesperada em aplicações.

Se uma regressão exigir recuperação, interrompa novas mudanças, preserve evidências e utilize o procedimento ensaiado. Reverter uma imagem isolada não recompõe automaticamente configuração, CRDs e integrações. A restauração administrativa deve ser testada com a versão e o contexto adequados. (argo-cd.readthedocs.io)

Uma volta emergencial à versão vulnerável deve ter aceite explícito do risco, contenção, responsável e prazo de saída. Não considere o incidente encerrado enquanto a correção não estiver novamente aplicada.

14. Cenário prático e trade-offs

Exemplo hipotético: uma plataforma compartilha Argo CD entre times que entregam uma API, workers e serviços internos.

Problema: a equipe precisa corrigir a plataforma sem transformar a janela de segurança em uma migração ampla.

Solução: manter a linha minor quando houver patch corrigido, testar renderizadores representativos e promover por instalação.

Implementação proposta: inventário, backup testado, aplicação descartável para hooks, canário funcional, revisão de permissões e atualização rastreada em Git.

Resultado esperado: evidência de correção e continuidade operacional, sem prometer redução percentual de incidentes ou ausência absoluta de indisponibilidade.

Uma instância compartilhada favorece padronização, mas exige avaliar a concentração de confiança. Instâncias separadas por ambiente ou domínio de segurança são uma alternativa arquitetural a considerar, com maior custo de operação. Para uma equipe pequena, um runbook curto e ensaiado pode ser melhor que uma nova plataforma de automação.

Este checklist é indicado para instalações críticas, multitenant ou reguladas. Não é necessário transformar um laboratório descartável em uma operação de mudança corporativa; ainda assim, credenciais reais e conectividade com produção eliminam a justificativa de tratar esse laboratório como inofensivo.

Alternativas a avaliar após a emergência

Essas opções são propostas arquiteturais, não substitutos para atualizar uma instância vulnerável. Para poucas aplicações e uma única equipe, evite adicionar plugins e instâncias sem benefício mensurável.

Resumo prático

• Identifique cada advisory e a exposição correspondente.
• Escolha uma release corrigida sem ampliar desnecessariamente a migração.
• Teste comportamento permitido e negado, não apenas login e interface.
• Preserve o proprietário da instalação e valide os artefatos em execução.
• Separe contenção, atualização, investigação e rotação de credenciais.
• Encerre a mudança com evidências e um caminho de recuperação exercitado.

Conclusão

A atualização do Argo CD v3.5.4 deve ser conduzida como uma mudança de segurança na cadeia de entrega. Para DevOps, SRE e Platform Engineering, o objetivo não é apenas trocar uma tag: é demonstrar que a plataforma continua entregando software dentro das fronteiras de confiança aprovadas.

Um processo maduro combina urgência proporcional ao risco, testes representativos e recuperação verificável. Esse equilíbrio torna o GitOps uma prática operacional sustentável, em vez de uma dependência crítica sem plano de manutenção.