Implementazioni sicure con Config Management

Questo documento mostra agli operatori di cluster e agli amministratori di piattaforma come implementare in sicurezza le modifiche in più ambienti utilizzando Config Management. Config Management può aiutarti a evitare errori che interessano tutti i tuoi ambienti contemporaneamente.

Config Management consente di gestire cluster singoli, cluster multi-tenant e configurazioni Kubernetes multi-cluster utilizzando i file archiviati in un repository Git. Config Management combina tre tecnologie: Config Sync, Policy Controller e Config Connector. Config Sync controlla la presenza di aggiornamenti di tutti i file nel repository Git e applica automaticamente le modifiche a tutti i cluster pertinenti. Policy Controller gestisce e applica i criteri per gli oggetti nei cluster. Config Connector utilizza le risorse personalizzate di Google Kubernetes Engine (GKE) per gestire le risorse cloud.

Le configurazioni di Config Sync possono rappresentare diversi elementi, tra cui:

• Oggetti GKE standard, come risorse NetworkPolicies, risorse DaemonSets o risorse RoleBindings.
• Risorse Google Cloud, ad esempio istanze di Compute Engine o database Cloud SQL, attraverso Config Connector.
• Vincoli relativi alla configurazione stessa tramite Policy Controller.

Config Management è particolarmente adatto per eseguire il deployment di configurazioni, criteri e carichi di lavoro necessari per eseguire la piattaforma che crei su GKE Enterprise, ad esempio agenti di sicurezza, agenti di monitoraggio e gestori dei certificati.

Sebbene sia possibile eseguire il deployment di applicazioni rivolte agli utenti con Config Management, non è consigliabile collegare il loro ciclo di vita delle release al ciclo di vita della release dei carichi di lavoro amministrativi menzionati in precedenza. Ti consigliamo invece di utilizzare uno strumento dedicato al deployment delle applicazioni, ad esempio uno strumento di deployment continuo, in modo che i team delle applicazioni possano essere responsabili del proprio programma di release.

Config Management è un prodotto potente in grado di gestire molti elementi, per cui sono necessari dei sistemi di protezione per evitare errori con un impatto significativo. Questo documento descrive diversi metodi per creare delle barriere. La prima sezione riguarda le implementazioni graduali, la seconda si concentra su test e convalide, mentre la terza spiega come utilizzare Policy Controller per creare sistemi di protezione. La quarta sezione mostra come monitorare i deployment di Config Management.

Puoi utilizzare la maggior parte dei metodi illustrati in questo documento, anche se utilizzi solo Config Sync e non il prodotto Config Management completo. Se non utilizzi il prodotto Config Management completo, ma vuoi comunque implementare i metodi che coinvolgono Policy Controller, puoi farlo utilizzando Gatekeeper. Le eccezioni a questa regola sono i metodi che si basano sulla pagina Config Management nella console Google Cloud, ad esempio l'aggiornamento della configurazione di Config Management nella console Google Cloud. Puoi anche utilizzare contemporaneamente diversi metodi descritti in questo documento. Nella sezione seguente, una tabella indica quali metodi sono compatibili per l'uso simultaneo.

Nota: questo tutorial utilizza un repository Git per spiegare come implementare le implementazioni. Sono supportate anche le immagini OCI e i grafici Helm.

Implementazione di implementazioni graduali con Config Management

In un ambiente multi-cluster, che è una situazione comune per gli utenti di GKE Enterprise, sconsigliamo di applicare una modifica alla configurazione a tutti i cluster contemporaneamente. Un'implementazione graduale, un cluster per cluster o persino uno spazio dei nomi per spazio dei nomi, se utilizzi gli spazi dei nomi come confine tra le applicazioni, è molto più sicura perché riduce il raggio di attacco di qualsiasi errore.

Di seguito sono riportati diversi modi per implementare le implementazioni graduali con Config Management:

• Utilizza i commit o i tag Git per applicare manualmente le modifiche che vuoi ai cluster.
• Utilizza i rami Git per applicare automaticamente le modifiche quando vengono unite. Puoi utilizzare rami diversi per gruppi di cluster diversi.
• Utilizza gli oggetti ClusterSelector e NamespaceSelector per applicare selettivamente modifiche a sottogruppi di cluster o spazi dei nomi.

Tutti i metodi per le implementazioni graduali presentano vantaggi e svantaggi. La seguente tabella mostra quali di questi metodi puoi utilizzare contemporaneamente.

I modelli X sono compatibili con Y?	commit o tag Git	Rami Git	Selettori di cluster	Selettori dello spazio dei nomi
commit o tag Git		Non compatibile	Compatibile	Compatibile
Rami Git	Non compatibile		Compatibile	Compatibile
Selettori di cluster	Compatibile	Compatibile		Compatibile
Selettori dello spazio dei nomi	Compatibile	Compatibile	Compatibile

La seguente struttura decisionale ti aiuta a decidere quando utilizzare uno dei metodi di implementazione graduale.

Nota: Config Management consente di sincronizzare le configurazioni da più repository: un repository per le configurazioni con ambito cluster e un repository facoltativo per spazio dei nomi. Sebbene l'utilizzo dei selettori dello spazio dei nomi sia diverso quando si utilizzano più repository, puoi comunque applicare tutti gli altri metodi descritti in questa sezione ai repository da cui sincronizzi le configurazioni.

Usa commit o tag Git

Rispetto agli altri metodi di implementazione graduale, l'utilizzo di commit o tag Git offre il massimo controllo ed è il più sicuro. Puoi utilizzare la pagina Gestione della configurazione nella console per aggiornare più cluster contemporaneamente. Utilizza questo metodo se vuoi applicare le modifiche ai cluster una alla volta e controllare esattamente quando succede.

In questo metodo, puoi "bloccare" ogni cluster su una versione specifica (un commit o un tag) del repository di Config Management. Questo metodo è simile all'utilizzo del commit Git come tag dell'immagine container. Per implementare questo metodo, specifica il commit, il tag o l'hash nel campo spec.git.revision della risorsa personalizzata RootSync o RepoSync.

Se gestisci le tue risorse personalizzate RootSync o RepoSync con uno strumento come kustomize, puoi ridurre il lavoro manuale necessario per implementare le modifiche. Con questo strumento, basta modificare il parametro revision in una sola posizione, quindi applicare selettivamente la nuova risorsa personalizzata RootSync o RepoSync ai cluster nell'ordine e al ritmo che preferisci.

Inoltre, se utilizzi Config Management (e non Config Sync), puoi accedere alla pagina Config Management nella console Google Cloud. Questa pagina consente di aggiornare contemporaneamente il parametro revision per più cluster appartenenti alla stessa flotta. Se disponi di un sistema automatico per aggiornare la configurazione di Config Management, ti consigliamo di non utilizzare la console per modificare questa configurazione.

Ad esempio, la seguente definizione di RootSync configura Gestione della configurazione in modo che utilizzi il tag 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: [e-mail]:anthos/config-management.git
    revision: 1.2.3
    auth: ssh

Se applichi questa configurazione al tuo cluster, Config Management utilizzerà il tag 1.2.3 del repository example.com:anthos/config-management.git.

Per aggiornare un cluster, modifica il campo spec.git.revision con il nuovo valore per il cluster. In questo modo puoi definire quali cluster vengono aggiornati e quando. Se devi eseguire il rollback di una modifica, ripristina il valore precedente del campo spec.git.revision.

Il seguente diagramma illustra il processo di implementazione di questo metodo. Innanzitutto, esegui il commit delle modifiche nel repository Config Management, quindi aggiorni le definizioni di RootSync su tutti i cluster:

Consigliamo di eseguire queste operazioni:

• Utilizza ID commit Git anziché tag. A causa del modo in cui Git funziona, hai la garanzia che non cambieranno mai. Ad esempio, un git push --force non può modificare il commit utilizzato da Config Management. Questo approccio è utile a fini di controllo e per tenere traccia del commit utilizzato nei log. Inoltre, a differenza dei tag, non è necessario eseguire ulteriori passaggi per eseguire il commit degli ID.
• Se preferisci utilizzare i tag Git anziché gli ID commit Git e stai usando GitLab, proteggi i tag per evitare che vengano spostati o eliminati. Le altre principali soluzioni Git non dispongono di questa funzionalità.
• Se vuoi aggiornare più cluster contemporaneamente, puoi farlo nella pagina della console di gestione della configurazione. Per poter aggiornare più cluster contemporaneamente, questi devono far parte della stessa flotta (e far parte dello stesso progetto).

Usa rami Git

Se vuoi applicare le modifiche ai cluster non appena vengono unite nel repository Git, configura Config Management in modo che utilizzi i rami Git anziché commit o tag. Con questo metodo puoi creare più rami di lunga durata nel repository Git e configurare la gestione della configurazione in cluster diversi per leggere la sua configurazione da rami diversi.

Ad esempio, un pattern semplice ha due rami:

• Un ramo staging per i cluster non di produzione.
• Un ramo master per i cluster di produzione.

Avviso: se hai a che fare con un numero elevato di cluster e ambienti, potresti aver bisogno di un numero elevato di rami. Questa operazione può diventare rapidamente difficile da gestire. Ecco perché consigliamo di utilizzare i commit Git.

Per i cluster non di produzione, crea l'oggetto RootSync o RepoSync con il campo spec.git.branch impostato su staging. Per i cluster di produzione, crea l'oggetto RootSync o RepoSync con il parametro spec.git.branch impostato su master.

Ad esempio, la seguente definizione di RootSync configura Config Management in modo da utilizzare il ramo master:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  git:
    repo: [e-mail]:anthos/config-management.git
    branch: master
    auth: ssh

Il seguente diagramma illustra la procedura di implementazione di questo metodo:

Puoi adattare questo pattern a esigenze specifiche, utilizzando più di due rami o utilizzando rami mappati a qualcosa di diverso dagli ambienti. Se è necessario eseguire il rollback di una modifica, utilizza il comando git revert per creare un nuovo commit nello stesso ramo che ripristina le modifiche dal commit precedente.

Consigliamo di eseguire queste operazioni:

• Quando gestisci più cluster, utilizza almeno due rami Git per distinguere i cluster di produzione da quelli non di produzione.
• La maggior parte delle soluzioni Git consente di utilizzare la funzionalità dei rami protetti per evitare le eliminazioni o le modifiche non esaminate di questi rami. Per ulteriori informazioni, consulta la documentazione relativa a GitHub, GitLab e Bitbucket.

Utilizzo degli oggetti ClusterSelector e NamespaceSelector

I rami Git sono un ottimo modo per eseguire un'implementazione graduale delle modifiche in più cluster che alla fine avranno tutti gli stessi criteri. Tuttavia, se vuoi implementare una modifica solo per un sottoinsieme di cluster o di spazi dei nomi, utilizza gli oggetti ClusterSelector e NamespaceSelector. Questi oggetti hanno un obiettivo simile: consentono di applicare oggetti solo a cluster o spazi dei nomi con etichette specifiche.

Ad esempio:

• Utilizzando gli oggetti ClusterSelector, puoi applicare criteri diversi ai cluster, a seconda del paese in cui si trovano, per vari regimi di conformità.
• Utilizzando gli oggetti NamespaceSelector, puoi applicare criteri diversi agli spazi dei nomi utilizzati da un team interno e da un fornitore esterno.

Gli oggetti ClusterSelector e NamespaceSelector consentono inoltre di implementare test avanzati e metodologie di rilascio, come le seguenti:

• Release canary di criteri, in cui esegui il deployment di un nuovo criterio in un piccolo sottoinsieme di cluster e spazi dei nomi per un lungo periodo di tempo per esaminare l'impatto del criterio.
• Test A/B, in cui esegui il deployment di versioni diverse dello stesso criterio in cluster diversi per studiare la differenza dell'impatto delle versioni del criterio e quindi scegliere la migliore di cui eseguire il deployment ovunque.

Immagina, ad esempio, un'organizzazione con diversi cluster di produzione. Il team della piattaforma ha già creato due categorie di cluster di produzione, chiamati canary-prod e prod, utilizzando Config Management, Cluster e oggetti ClusterSelector (consulta la sezione Utilizzare ClusterSelectors).

Il team della piattaforma vuole implementare un criterio con Policy Controller per applicare la presenza di un'etichetta del team negli spazi dei nomi in modo da identificare a quale team appartiene ogni spazio dei nomi. Ha già implementato una versione di questo criterio in modalità di prova e ora vuole applicarla su un numero ridotto di cluster. Utilizzando oggetti ClusterSelector, creano due diverse risorse K8sRequiredLabels che vengono applicate a cluster diversi.

• La risorsa K8sRequiredLabels viene applicata ai cluster di tipo prod, con un parametro enforcementAction impostato su dryrun:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: prod
  Spec:
    enforcementAction: dryrun
    match:
      kinds:
        - apiGroups: [""]
          kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

• La risorsa K8sRequiredLabels viene applicata ai cluster di tipo canary-prod, senza il parametro enforcementAction, il che significa che il criterio viene effettivamente applicato:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: canary-prod
  spec:
    match:
      kinds:
        - apiGroups: [""]
      kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

L'annotazione configmanagement.gke.io/cluster-selector consente al team di applicare il criterio solo in cluster di tipo canary-prod, impedendo che eventuali effetti collaterali indesiderati si diffondano all'intero parco risorse di produzione. Per ulteriori informazioni sulla funzionalità di prova di Policy Controller, consulta Creazione di vincoli.

Consigliamo di eseguire queste operazioni:

• Utilizza gli oggetti ClusterSelector e NamespaceSelector se devi applicare una modifica alla configurazione solo a un sottoinsieme di cluster o spazi dei nomi per un tempo indefinito o per un periodo di tempo prolungato.
• Se implementi una modifica utilizzando i selettori, presta molta attenzione. Se utilizzi i commit Git, qualsiasi errore interessa un solo cluster alla volta, perché stai implementando cluster per cluster. Ma se utilizzi rami Git, qualsiasi errore può interessare tutti i cluster che utilizzano quel ramo. Se utilizzi i selettori, l'errore può interessare tutti i cluster contemporaneamente.

Implementazione di revisioni, test e convalide

Un vantaggio di Config Management è che gestisce tutto in modo dichiarativo: risorse Kubernetes, risorse cloud e criteri. Ciò significa che i file in un sistema di gestione del controllo del codice sorgente rappresentano le risorse (file Git, nel caso di Config Management). Questa caratteristica consente di implementare flussi di lavoro di sviluppo già in uso per il codice sorgente di un'applicazione: revisioni e test automatici.

Implementa le revisioni

Poiché Config Management si basa su Git, puoi utilizzare la tua soluzione Git che preferisci per ospitare il repository di Config Management. La tua soluzione Git include probabilmente una funzionalità di revisione del codice, che puoi utilizzare per rivedere le modifiche apportate al repository Config Management.

Le best practice per la revisione delle modifiche al repository di Config Management sono le stesse di una normale revisione del codice, come segue:

• Esercitati con lo sviluppo basato su trunk.
• Utilizzano piccoli batch.
• Assicurati che la revisione del codice venga eseguita in modo sincrono o almeno prontamente.
• La persona che esamina e approva la modifica non deve essere la stessa che l'ha suggerita.

Data la sensibilità del codebase di Config Management, ti consigliamo inoltre di effettuare le seguenti configurazioni, se possibile con la tua soluzione Git:

• Proteggi i rami utilizzati direttamente dai cluster. Consulta la documentazione per GitHub, GitLab e Bitbucket. GitLab ti consente anche di proteggere i tag.
• Una volta protetti i rami, puoi perfezionare le approvazioni necessarie per unire una modifica:
  • Su GitHub, abilita le revisioni richieste e, facoltativamente, utilizza il file CODEOWNERS per controllare chi può approvare le modifiche per le sottosezioni del repository.
  • Per GitLab, segui i suggerimenti per gestire chi può approvare le richieste di unione nell'articolo Best practice per la gestione dei criteri con Config Management e GitLab.
  • Su Bitbucket, combina i recensori predefiniti con i controlli di unione predefiniti. Facoltativamente, puoi utilizzare un plug-in Proprietari del codice per Bitbucket Server è disponibile in Atlassian Marketplace per controllare chi può approvare le modifiche per le sottosezioni del repository.

Utilizzando queste diverse funzionalità, puoi applicare le approvazioni per ogni richiesta di modifica al codebase di Config Management. Ad esempio, puoi assicurarti che ogni modifica venga approvata almeno da un membro del team della piattaforma (che gestisce il parco risorse di cluster) e da un membro del team di sicurezza (che è responsabile della definizione e dell'implementazione dei criteri di sicurezza).

Consigliamo di eseguire queste operazioni:

• Applica le revisioni tra colleghi nel repository di Config Management e proteggi i rami Git utilizzati dai cluster.

Implementare test automatici

Una best practice comune quando si lavora su un codebase consiste nell'implementare l'integrazione continua. Ciò significa che configuri i test automatici da eseguire quando viene creata o aggiornata una richiesta di modifica. I test automatici sono in grado di rilevare molti errori prima che la richiesta di modifica venga esaminata da un essere umano. Questo stringi il ciclo di feedback per lo sviluppatore. Puoi implementare la stessa idea utilizzando gli stessi strumenti per il repository di Config Management.

Ad esempio, un buon punto di partenza è eseguire automaticamente il comando nomos vet in caso di nuove modifiche. Questo comando convalida che la sintassi del repository di Config Management sia valida. Puoi implementare questo test utilizzando Cloud Build seguendo il tutorial sulle configurazioni di convalida. Puoi integrare Cloud Build con le seguenti opzioni:

• Bitbucket, utilizzando i trigger di build.
• GitHub, utilizzando l'applicazione GitHub di Google Cloud Build. I trigger di build sono disponibili anche per GitHub, ma l'applicazione GitHub è il metodo di integrazione preferito.

Come puoi vedere nel tutorial sulle configurazioni di convalida, il test viene eseguito utilizzando un'immagine container. Di conseguenza, puoi implementare il test in qualsiasi soluzione di integrazione continua che esegue i container, non solo in Cloud Build. In particolare, puoi implementarlo con GitLab CI, seguendo questo esempio, che include anche i test per Policy Controller.

Per stringere ulteriormente il ciclo di feedback, puoi chiedere agli utenti di eseguire il comando nomos vet come hook di pre-commit Git. Un avvertimento è che alcuni utenti potrebbero non avere accesso ai cluster Kubernetes gestiti da Config Management e potrebbero non essere in grado di eseguire la convalida completa dalla propria workstation. Esegui il comando nomos vet --clusters "" per limitare la convalida ai controlli semantici e sintattici.

Puoi implementare qualsiasi altro test che ritieni necessario o utile. Se utilizzi Policy Controller, puoi implementare test automatici delle modifiche suggerite in base ai relativi criteri, come descritto in Testare le modifiche in base ai criteri di Policy Controller.

Consigliamo di eseguire queste operazioni:

• Implementa i test in una pipeline di integrazione continua. Esegui almeno il comando nomos vet su tutte le modifiche suggerite.

Utilizzo di Policy Controller

Nota: Policy Controller si basa sul progetto open source OPA Gatekeeper. Policy Controller è incluso solo in Config Management, non in Config Sync. Se utilizzi Config Sync nella sua forma autonoma, dovrai eseguire il deployment e gestire autonomamente OPA Gatekeeper per implementare i suggerimenti di questa sezione.

Policy Controller è un controller di ammissione dinamico Kubernetes. Quando installi e configuri Policy Controller, Kubernetes può rifiutare le modifiche non conformi alle regole predefinite, chiamate criteri.

Di seguito sono riportati due esempi di casi d'uso di Policy Controller:

• Forza l'applicazione di etichette specifiche sugli oggetti Kubernetes,
• Impedisci la creazione di pod con privilegi.

È disponibile una libreria di modelli di criteri per l'implementazione dei criteri più utilizzati, ma puoi scriverne di personalizzati con un potente linguaggio chiamato Rego. Utilizzando Policy Controller, puoi, ad esempio, limitare i nomi host che gli utenti possono configurare in un traffico in entrata (per ulteriori informazioni, vedi questo tutorial).

Nota: scrivere nuovi criteri per Policy Controller utilizzando Rego è una competenza avanzata, quindi non aspettarti che tutti gli utenti di Config Management siano in grado di farlo.

Come Config Sync, Policy Controller fa parte del prodotto Config Management. Policy Controller e Config Sync hanno casi d'uso diversi, ma complementari, come segue:

• Config Sync è uno strumento in stile GitOps che ti consente di creare qualsiasi oggetto Kubernetes, potenzialmente in più cluster contemporaneamente. Come menzionato nell'introduzione, Config Sync è particolarmente utile per la gestione dei criteri.
• Policy Controller consente di definire i criteri per gli oggetti che possono essere creati in Kubernetes. Questi criteri vengono definiti in risorse personalizzate, che sono a loro volta oggetti Kubernetes.

Le caratteristiche precedenti creano una relazione bidirezionale tra le due applicazioni. Puoi utilizzare Config Sync per creare i criteri applicati da Policy Controller e utilizzarli per controllare esattamente quali oggetti possono essere creati da Config Sync (o da qualsiasi altro processo), come illustrato nel diagramma seguente:

Il repository Git, Config Sync, Policy Controller, Kubernetes, un sistema di deployment continuo (CD) e gli utenti interagiscono tra loro nei seguenti modi:

• Gli utenti interagiscono con il repository Git di Config Management per creare, aggiornare o eliminare gli oggetti Kubernetes.
• Config Sync legge la configurazione dal repository Git di Config Management.
• Config Sync interagisce con il server API Kubernetes per creare oggetti, che includono criteri per Policy Controller.
• Il sistema CD interagisce anche con il server API Kubernetes per creare oggetti. Può creare vincoli per Policy Controller. Tuttavia, ti consigliamo di utilizzare Config Management per questo caso d'uso, in quanto offre una posizione centralizzata per gestire e testare i vincoli.
• Il server API Kubernetes accetta o rifiuta la creazione di oggetti da parte di Config Sync e dal sistema CD, in base alla risposta di Policy Controller.
• Policy Controller fornisce la risposta in base ai criteri che legge dal server API Kubernetes.

Il seguente diagramma illustra queste interazioni:

Policy Controller può prevenire le violazioni dei criteri che eludono i revisori e i test automatici, pertanto puoi considerarla l'ultima linea di difesa per i tuoi cluster Kubernetes. Policy Controller diventa più utile anche man mano che cresce il numero di revisori umani per Config Management. A causa del fenomeno del loafing sociale, maggiore è il numero di revisori, meno è probabile che applichino in modo coerente le regole definite nella tua organizzazione.

Testare le modifiche rispetto ai criteri di Policy Controller

Se utilizzi Policy Controller, puoi aggiungere alcuni passaggi alla pipeline di integrazione continua (vedi Implementare i test automatici) per testare automaticamente le modifiche suggerite in base ai criteri. L'automazione dei test offre un feedback più rapido e visibile alla persona che suggerisce la modifica. Se non testi le modifiche in base ai criteri nella pipeline di integrazione continua, devi fare affidamento sul sistema descritto in Monitorare le implementazioni per ricevere avvisi sugli errori di sincronizzazione di Config Management. Testare le modifiche rispetto alle norme espone qualsiasi violazione in modo chiaro e tempestivo alla persona che la suggerisce.

Puoi implementare questo test in Cloud Build seguendo il tutorial sull'utilizzo di Policy Controller in una pipeline CI. Come accennato in precedenza in Implementare test automatizzati, puoi integrare Cloud Build con GitHub e Bitbucket. Puoi anche implementare questo test con GitLab CI. Consulta questo repository per un esempio di implementazione.

Consigliamo di eseguire queste operazioni:

• Se utilizzi Policy Controller, convalida le modifiche suggerite in base ai relativi criteri nella pipeline di integrazione continua.

Monitoraggio delle implementazioni

Anche se implementi tutti i sistemi di protezione inclusi in questo documento, possono comunque verificarsi errori. Di seguito sono riportati due tipi di errori comuni:

• Errori che non rappresentano alcun problema per Config Sync, ma impediscono il corretto funzionamento dei carichi di lavoro, ad esempio un criterio NetworkPolicy eccessivamente restrittivo che impedisce la comunicazione tra i componenti del carico di lavoro.
• Errori che impediscono a Config Sync di applicare modifiche a un cluster, ad esempio un manifest Kubernetes non valido o un oggetto rifiutato da un controller di ammissione. I metodi descritti in precedenza dovrebbero rilevare la maggior parte di questi errori.

Il rilevamento degli errori descritti nel primo punto precedente è quasi impossibile a livello di Config Management, poiché questo richiede la comprensione dello stato di ciascuno dei carichi di lavoro. Per questo motivo, il rilevamento di questi errori è eseguito meglio dal tuo sistema di monitoraggio esistente, che ti avvisa quando un'applicazione funziona in modo anomalo.

Il rilevamento degli errori descritti nel secondo punto precedente, che dovrebbe essere raro se hai implementato tutti i sistemi di protezione, richiede una configurazione specifica. Per impostazione predefinita, Config Management scrive gli errori nei log (che troverai, per impostazione predefinita, in Cloud Logging). Gli errori vengono visualizzati anche nella pagina della console di gestione della configurazione. In genere né i log né la console sono sufficienti per rilevare errori, perché probabilmente non li monitori sempre. Il modo più semplice per automatizzare il rilevamento degli errori è eseguire il comando nomos status, che indica se si è verificato un errore in un cluster.

Puoi anche configurare una soluzione più avanzata con avvisi automatici per gli errori. Config Management espone le metriche nel formato Prometheus. Per ulteriori informazioni, consulta Monitoraggio di Config Management.

Una volta ottenute le metriche di Config Management nel sistema di monitoraggio, crea un avviso per ricevere una notifica quando la metrica gkeconfig_monitor_errors è maggiore di 0. Per ulteriori informazioni, consulta la pagina sulla gestione dei criteri di avviso per Cloud Monitoring o le regole di avviso per Prometheus.

Riepilogo dei meccanismi per implementazioni sicure con Config Management

La seguente tabella riassume i vari meccanismi descritti in precedenza in questo documento. Nessuno di questi meccanismi è esclusivo. Puoi scegliere di usarne alcuni o tutti, per scopi diversi.

Meccanismo	A cosa serve	Cosa non è utile	Esempio di caso d'uso
ID e tag commit Git	Utilizza ID o tag di commit Git specifici per controllare con precisione a quali modifiche del cluster vengono applicate.	Non utilizzare ID o tag di commit Git per differenze di lunga durata tra i cluster. Utilizza i selettori di cluster.	Tutti i cluster sono configurati per applicare il commit Git 12345. Apporti una modifica con un nuovo commit, abcdef, che vuoi testare. Puoi modificare la configurazione di un singolo cluster per utilizzare questo nuovo commit per convalidare la modifica.
Rami Git	Utilizza più rami Git quando vuoi implementare la stessa modifica in più ambienti, uno dopo l'altro.	Non utilizzare più rami Git per differenze di lunga durata tra i cluster. Le divisioni tra le due filiali si dividono in modo significativo e sarà difficile ricongiungersi.	Prima unisci la modifica nel ramo di gestione temporanea, dove verrà selezionata dai cluster di gestione temporanea. Quindi, unisci la modifica nel ramo master, dove verrà ritirata dai cluster di produzione.
Selettori di cluster e selettori dello spazio dei nomi	Utilizza i selettori per le differenze di lunga durata tra i cluster e gli spazi dei nomi.	Non utilizzare i selettori per un'implementazione graduale in più ambienti. Se vuoi testare una modifica prima nella gestione temporanea e poi eseguirne il deployment in produzione, utilizza rami Git separati.	Se i team delle applicazioni hanno bisogno dell'accesso completo ai cluster di sviluppo, ma dell'accesso in sola lettura ai cluster di produzione, utilizza l'oggetto ClusterSelector per applicare i criteri RBAC corretti solo ai cluster pertinenti.
Recensioni di altri colleghi	Utilizza le revisioni degli altri studenti per assicurarti che i team pertinenti approvino le modifiche.	I revisori non rilevano tutti gli errori, soprattutto elementi come gli errori di sintassi.	La tua organizzazione impone al team di sicurezza di esaminare le modifiche alla configurazione che interessano più sistemi. Chiedi a un membro del team di sicurezza di esaminare le modifiche.
Test automatici nella pipeline di integrazione continua	Utilizza i test automatici per individuare gli errori nelle modifiche suggerite.	I test automatici non possono sostituire del tutto un revisore. Usali entrambi.	L'esecuzione di un comando nomos vet su tutte le modifiche suggerite conferma che il repository sia una configurazione di Config Management valida.
Policy Controller	Applica criteri a livello di organizzazione e implementa sistemi di protezione direttamente a livello di server API Kubernetes.	Policy Controller non può essere utilizzato per creare, aggiornare o eliminare i criteri (questo è il ruolo di Config Management). Policy Controller può applicare solo i criteri.	Il team di sicurezza utilizza Config Management per creare un vincolo di Policy Controller per impedire agli utenti di creare container con privilegi, anche negli spazi dei nomi gestiti direttamente dai team delle applicazioni.
Testare le modifiche in base ai vincoli di Policy Controller.	Assicurati che Policy Controller non rifiuti le modifiche quando Config Management le applica.	Il test delle modifiche rispetto ai vincoli di Policy Controller in una pipeline di integrazione continua non sostituisce l'abilitazione di Policy Controller sui cluster.	Ogni spazio dei nomi deve avere un'etichetta "team" per identificarne il proprietario. Un utente vuole creare un nuovo spazio dei nomi e dimentica di aggiungere questa etichetta nella modifica suggerita. La pipeline di integrazione continua rileva l'errore prima che un essere umano esamini la modifica.
Monitorare gli errori di sincronizzazione	Assicurati che Config Management applichi effettivamente le modifiche ai cluster.	Gli errori di sincronizzazione si verificano solo se Config Management tenta di applicare un repository non valido o se il server API Kubernetes rifiuta alcuni degli oggetti. Se non hai codificato tutti i vincoli nei criteri di Policy Controller, le risorse che violano questi vincoli non verranno rilevate.	Un utente ignora tutti i test e le revisioni ed esegue il commit di una modifica non valida nel repository di Config Management. Questa modifica non può essere applicata ai tuoi cluster. Se monitori gli errori di sincronizzazione, riceverai un avviso in caso di errore.

Esempio di strategia di implementazione

Questa sezione utilizza i concetti presentati nel resto di questo articolo per aiutarti a creare una strategia di implementazione end-to-end in tutti i cluster della tua organizzazione. Questa strategia presuppone che tu disponga di parchi risorse separati per sviluppo, gestione temporanea e produzione (come mostrato nell'Esempio del parco risorse 1 - Approccio 1).

Avviso: questa strategia di implementazione è complessa. L'implementazione ha senso solo se hai un'infrastruttura complessa con almeno 2 parchi risorse e almeno 3 cluster per parco risorse. Se disponi di un numero elevato di parchi risorse, ma con un singolo cluster in ciascuno, puoi adattare questa strategia impostando "parchi risorse canary" anziché "cluster canary".

In questo scenario, configurerai ogni cluster per la sincronizzazione con il repository Git di Config Management utilizzando un commit Git specifico. Il deployment di una modifica in un determinato parco risorse è un processo in quattro passaggi:

1. Devi aggiornare un singolo cluster (il "canary") nel parco risorse in modo da utilizzare prima il nuovo commit.
2. Puoi verificare che tutto funzioni come previsto eseguendo test e monitorando l'implementazione.
3. Aggiornerai gli altri cluster nel parco risorse.
4. Verifica nuovamente che tutto funzioni come previsto.

Per eseguire il deployment di una modifica in tutti i cluster, ripeti questo processo per ogni parco risorse. Tecnicamente puoi applicare questo metodo con qualsiasi commit Git, da qualsiasi ramo. Tuttavia, ti consigliamo di adottare la seguente procedura per identificare i problemi nelle prime fasi del processo di revisione:

1. Quando qualcuno apre una richiesta di modifica nel repository Git di Config Management, esegui il deployment della modifica in uno dei cluster di sviluppo.
2. Se la richiesta di modifica viene accettata e unita nel ramo principale, esegui il deployment completo in tutti i parchi risorse come descritto in precedenza.

Anche se alcune modifiche potrebbero avere come target solo un parco risorse specifico, ti consigliamo di eseguire il deployment di tutte le modifiche in tutti i parchi risorse alla fine. Questa strategia elimina il problema di monitorare quale parco risorse deve sincronizzare con un determinato commit. Presta particolare attenzione alle modifiche che hanno come target solo il parco risorse di produzione, perché non sarebbero stati possibili test adeguati nei parchi risorse precedenti. Ad esempio, questo significa attendere più a lungo per la comparsa dei problemi tra il deployment nei cluster canary e il resto dei cluster.

Per riassumere, un deployment end-to-end completo ha il seguente aspetto:

1. Un utente apre una richiesta di modifica.
2. Vengono eseguiti test e convalide automatiche e poi viene eseguita una revisione manuale.
3. Puoi attivare un job manualmente per eseguire il deployment della modifica nel cluster canary nel parco risorse di sviluppo. Test automatici end-to-end eseguiti in questo cluster.
4. Se non ci sono problemi, unisci la richiesta di modifica nel ramo principale.
5. L'unione attiva un job automatizzato per eseguire il deployment del nuovo commit di punta del ramo principale nel cluster canary nel parco risorse di sviluppo. In questo cluster vengono eseguiti test automatici end-to-end (per rilevare potenziali incompatibilità tra due richieste di modifica che sono state create e unite approssimativamente contemporaneamente).
6. I seguenti job vengono eseguiti uno dopo l'altro (puoi attivarli manualmente o dopo un periodo di tempo predefinito per consentire le segnalazioni di regressioni da parte degli utenti):
   1. Esegui il deployment in tutti i cluster del parco risorse di sviluppo.
   2. Esegui test e convalide nei cluster del parco risorse di sviluppo.
   3. Esegui il deployment nel cluster canary del parco risorse di gestione temporanea.
   4. Esegui test e convalide nel cluster canary del parco risorse di gestione temporanea.
   5. Esegui il deployment in tutti i cluster del parco risorse di gestione temporanea.
   6. Esegui test e convalide nei cluster del parco risorse di gestione temporanea.
   7. Esegui il deployment nel cluster canary del parco risorse di produzione.
   8. Esegui test e convalide nel cluster canary del parco risorse di produzione.
   9. Esegui il deployment in tutti i cluster del parco risorse di produzione.
   10. Esegui test e convalide nei cluster del parco risorse di produzione.

Passaggi successivi

• Scopri di più sul monitoraggio di Config Management.
• Ulteriori informazioni sui parchi risorse.
• Scopri come convalidare la tua app in base ai criteri aziendali in una pipeline di integrazione continua.
• Scopri le best practice per la gestione dei criteri con Config Management e GitLab.