Sommario

Nelle architetture Kubernetes enterprise su larga scala, l'adozione di un unico strumento GitOps per gestire sia le primitive di sistema sia i carichi applicativi genera una pericolosa collisione di privilegi e responsabilità. Questo articolo descrive il pattern architetturale a doppio motore adottato su Google Kubernetes Engine (GKE): delegare la configurazione dell'infrastruttura di cluster (CRD, policy di rete, RBAC e guardrail di sicurezza) ad Anthos Config Sync tramite Google Cloud Fleet, e riservare ad Argo CD la gestione del ciclo di vita dei deployment applicativi all'interno di namespace rigidamente perimetrati.

L'illusione del repository GitOps unico e la collisione dei privilegi

Nel percorso verso l'adozione del paradigma GitOps, molte organizzazioni tentano di utilizzare un solo controller — tipicamente Argo CD o Flux — per riconciliare l'intero stack, dal bootstrap dei nodi fino all'applicazione di frontend. In ambienti enterprise regolamentati (come quelli bancari o assicurativi), questo approccio monolitico mostra rapidamente crepe strutturali:

• Sovraestensione dei privilegi (Overprivileged ServiceAccount): Per installare operatori complessi, Custom Resource Definitions (CRD), ClusterRole e NetworkPolicy, il controller GitOps deve operare con permessi di cluster-admin. Se lo stesso controller è accessibile ai team di sviluppo per registrare nuove applicazioni, qualsiasi errore o compromissione di un manifest applicativo espone l'intero cluster a rischi di privilege escalation.
• Conflitto sui cicli di vita: L'infrastruttura di piattaforma ha un ritmo di rilascio controllato, soggetto a verifiche di conformità preventive e rigorosa approvazione del platform engineering. Le applicazioni di business richiedono invece elevata frequenza di rilascio, canary deployment continui, rollback automatici e visibilità self-service per gli sviluppatori.
• Assenza di enforcement gerarchico multi-cluster: Gestire la baseline di conformità su decine di cluster GKE tramite Argo CD richiede complesse strutture di ApplicationSet che, tuttavia, non impediscono a un amministratore locale o a una procedura di emergenza di modificare temporaneamente lo stato del cluster senza che il drift venga sovrascritto in modo deterministico a livello kernel del control plane.

La soluzione architetturale consiste nell'introdurre un disaccoppiamento esplicito: due motori GitOps specializzati per due domini di responsabilità distinti.

Architettura Dual-Engine: Config Sync per la Platform e Argo CD per i Tenant

Il pattern a doppio motore separa nettamente la sovranità sull'infrastruttura dalla libertà applicativa dei tenant:

Ingrandisci

1. Il ruolo di Anthos Config Sync (RootSync)

Anthos Config Management (ACM), e nello specifico il componente open source Config Sync, opera come estensione nativa del control plane di GKE. Attraverso l'oggetto RootSync, il platform team sincronizza uno o più repository Git gestiti centralmente con autenticazione federata tramite Workload Identity (senza memorizzare credenziali statiche nel cluster).

Config Sync è l'unico componente a detenere permessi di cluster-admin. Il suo scopo è:

• Creare e configurare i namespace dei tenant con le relative quote di risorse (ResourceQuota, LimitRange).
• Applicare i baseline di sicurezza: Policy Controller (Gatekeeper/OPA), regole di isolamento di rete e configurazione di default per il service mesh.
• Effettuare il deployment e l'aggiornamento controllato della stessa istanza di Argo CD.

2. Il ruolo di Argo CD per l'Application Delivery

Argo CD non ha visibilità né permessi a livello cluster. Viene eseguito con un ServiceAccount confinato ai namespace applicativi definiti da Config Sync. Gli sviluppatori interagiscono con la UI e la CLI di Argo CD per:

• Gestire l'orchestrazione dei rilasci tramite Sync Waves e Sync Phases.
• Visualizzare i log, le metriche di salute delle applicazioni e lo storico delle revisioni.
• Eseguire progressive delivery (Argo Rollouts) e rollback istantanei senza mai poter violare i perimetri di sicurezza imposti a monte.

Manifest di Configurazione: RootSync e Scoping RBAC di Argo CD

Di seguito viene illustrato il manifest RootSync utilizzato per collegare il cluster GKE al repository di configurazione centrale dell'infrastruttura:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync-platform
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/enterprise-bank/gke-fleet-platform.git
    branch: main
    dir: "clusters/production/core-banking"
    auth: gcenode
  override:
    reconcileTimeout: 5m

All'interno di questo repository di piattaforma, Config Sync applica la configurazione di Argo CD limitandone il raggio d'azione (AppProject) ai soli namespace autorizzati, vietando espressamente la gestione di risorse a livello di cluster:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: payments-tenant-project
  namespace: argocd
spec:
  description: "Progetto isolato per il dominio applicativo pagamenti"
  sourceRepos:
    - "https://github.com/enterprise-bank/payments-workloads.git"
  destinations:
    - namespace: "tenant-payments"
      server: "https://kubernetes.default.svc"
  # Blocco preventivo: Argo CD non può creare o toccare risorse cluster-scoped
  clusterResourceWhitelist: []
  clusterResourceBlacklist:
    - group: "*"
      kind: "CustomResourceDefinition"
    - group: "rbac.authorization.k8s.io"
      kind: "ClusterRole"
    - group: "rbac.authorization.k8s.io"
      kind: "ClusterRoleBinding"
    - group: "networking.k8s.io"
      kind: "NetworkPolicy"
  namespaceResourceBlacklist:
    - group: "configsync.gke.io"
      kind: "*"

Gestione del Drift e Risoluzione dei Conflitti tra i due Motori

La compresenza di due controller GitOps sul medesimo cluster richiede regole chiare di demarcazione per prevenire loop infiniti di riconciliazione (sync fights):

• Gerarchia delle Annotazioni: Config Sync etichetta ogni oggetto gestito con l'annotazione configmanagement.gke.io/managed: enabled. Se Argo CD tenta di modificare un oggetto appartenente al platform team, la chiamata API fallisce a livello di admission webhook grazie alle policy imposte da Policy Controller.
• Riconciliazione Deterministica del Drift: Se un utente con permessi eccezionali modifica manualmente una risorsa di cluster (es. allentando una regola di firewall), Config Sync ripristina la configurazione di Git entro pochi secondi, emettendo un allarme verso Cloud Monitoring.
• Separazione dei Repository: Il repository di piattaforma (platform-fleet-config.git) è accessibile in scrittura solo al team Platform/SRE tramite PR con revisione obbligatoria di security. I repository dei tenant (payments-workloads.git) sono di proprietà esclusiva dei team di sviluppo.

Conclusione

La separazione tra governance dell'infrastruttura e ciclo di vita delle applicazioni non è solo un principio organizzativo, ma un requisito architetturale fondamentale per il successo di Kubernetes in contesti regolamentati.

Adottare Anthos Config Sync come guardrail di sistema a livello di fleet GKE e Argo CD come motore di consegna applicativa combina il meglio dei due mondi: determinismo crittografico e compliance a riposo per la sicurezza aziendale, uniti a flessibilità, velocità e un'esperienza di sviluppo moderna per i team applicativi.