GitOps Policy-as-Code: Fortalecendo o Kubernetes com Argo CD e Kyverno

À medida que ambientes de computação em nuvem amadurecem, o uso de GitOps com Argo CD tornou-se o padrão ouro para infraestrutura declarativa e self-healing. No entanto, a agilidade do deployment contínuo traz um desafio inerente: sem guardrails bem definidos, recursos mal configurados ou inseguros podem chegar à produção sem resistência.

Para empresas que buscam escalar com segurança, a resposta não está em processos manuais de checagem, mas na automação da governança através de Policy-as-Code. Este artigo analisa a integração técnica entre Kyverno e Argo CD, demonstrando como transformar regras de segurança em código versionado, garantindo conformidade sem sacrificar a velocidade do pipeline.

O papel do Kyverno como motor de políticas

O Kyverno, projeto graduado da CNCF, atua como um motor de políticas nativo para Kubernetes. Diferente de outras ferramentas, ele processa tudo usando YAML padrão, o que reduz a barreira de entrada para times de engenharia acostumados com o ecossistema K8s. Ele opera no nível de admission controller, interceptando requisições antes que alcancem o cluster.

Sua eficácia reside em quatro capacidades principais:

• Validate: Bloqueia ou audita recursos fora das regras estabelecidas.
• Mutate: Ajusta recursos automaticamente para conformidade antes do deployment.
• Generate: Cria recursos necessários por política.
• Cleanup: Remove recursos órfãos ou obsoletos de forma agendada.

Por que integrar Kyverno com Argo CD?

Quando combinamos o estado da infraestrutura via Git (Argo CD) com a motorização de políticas do Kyverno, alcançamos o verdadeiro GitOps secure-by-design. Os benefícios para o cenário brasileiro de TI — frequentemente sob pressão de conformidade (LGPD, normas setoriais) — são claros: rastreabilidade total, auditoria simplificada e enforced compliance.

Essa abordagem permite que mudanças de segurança sejam promovidas seguindo o mesmo fluxo das aplicações: um Pull Request altera a política, o Argo CD sincroniza o cluster e o Kyverno entra em ação. A transição entre modo Audit (apenas coleta de dados) e Enforce (bloqueio ativo) torna-se um exercício de gestão documental e versionamento de código.

Estrutura de implementação: GitOps no fluxo de trabalho

O setup ideal utiliza um padrão de "App-of-Apps" no Argo CD, onde o estado do cluster é refletido fielmente pelo repositório Git. A hierarquia recomendada abaixo, adotada por frameworks de desenvolvimento modernos, garante organização:

Copiarglobal-infra/
  infra-services/  #contém manifests de Application para Kyverno + policies
    kyverno.yaml
    kyverno-policies.yaml
  kyverno/              #child app para Kyverno
    Chart.yaml
    values.yaml
  kyverno-policies/     #child app para políticas
    Chart.yaml
    values.yaml
    templates/          #suas políticas customizadas

Configuração do deployment

O primeiro passo é garantir que o Kyverno seja implantado corretamente via Argo CD. O uso de sync-wave é crucial para assegurar que os CRDs necessários estejam disponíveis antes das políticas.

infra-services/kyverno.yaml

CopiarapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kyverno
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "1"
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true
spec:
  project: default
  source:
    repoURL: https://github.com/demo-infra.git
    targetRevision: main
    path: kyverno
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: kyverno
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Destacamos o uso de ServerSideDiff=true e IncludeMutationWebhook=true. Para times de SRE, é comum o aparecimento de alertas irrelevantes porque o Kyverno altera o recurso (mutação) após o deployment. Essas opções evitam ruído no dashboard do Argo CD.

Implementando Políticas de Segurança

Após configurar o motor, instalamos as políticas. O gerenciamento através de um chart Helm permite utilizar o catálogo da comunidade do Kyverno, mantendo suas regras customizadas (dentro da pasta templates/) separadas das regras base.

Exemplo prático: Restrição de IPs externos

Abaixo, um exemplo de política para mitigar riscos de man-in-the-middle (CVE-2020-8554), impedindo o uso indevido de externalIPs no seu cluster:

CopiarapiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: restrict-external-ips
 annotations:
   policies.kyverno.io/title: Restrict External IPs
   policies.kyverno.io/category: Best Practices
   policies.kyverno.io/severity: medium
   policies.kyverno.io/description: "Service externalIPs can be used for a MITM attack (CVE-2020-8554)."
spec:
 validationFailureAction: Audit
 background: true
 rules:
 - name: check-ips
     match:
       any:
         - resources:
             kinds:
               - Service
     validate:
       message: externalIPs are not allowed.
       pattern:
         spec:
           X(externalIPs): "null"

Ao manter o validationFailureAction como Audit, o time de TI pode avaliar o impacto da regra antes de passar para Enforce.

Visibilidade e Monitoramento

Um benefício crítico dessa integração é a visibilidade. Quando um deployment falha devido ao violar uma política no modo Enforce, o erro é exibido diretamente no Argo CD UI, reduzindo drasticamente o Mean Time to Resolution (MTTR) para os times de plataforma.

Para modos de auditoria, utilize comandos como kubectl get policyreport -A. Eles consolidam o histórico de conformidade, fornecendo aos gestores relatórios tangíveis sobre o estado de segurança da infraestrutura.

---

Artigo originalmente publicado por Albena Galabova, Igtix em Cloud Native Computing Foundation.