Tutorial: proteggere GKE Enterprise

---

GKE Enterprise fornisce una piattaforma coerente per creare e distribuire servizi sicuri, con funzionalità di sicurezza integrate a ogni livello che funzionano separatamente e insieme per fornire una difesa approfondita contro i problemi di sicurezza. Questo tutorial introduce alcune delle potenti funzionalità di sicurezza di GKE Enterprise utilizzando il deployment di esempio di Anthos su Google Cloud. Il deployment di esempio di Anthos esegue il deployment di un ambiente pratico GKE Enterprise reale con un cluster GKE, una mesh di servizi e un'applicazione Bank of GKE Enterprise con più microservizi.

Nota :se non hai mai utilizzato GKE Enterprise e il deployment di esempio di Anthos, prima di provare questo tutorial, vai a Esplora GKE Enterprise per installare il deployment e scoprire le funzionalità e i concetti di GKE Enterprise tramite la nostra applicazione di esempio.

Obiettivi

In questo tutorial, vengono presentate alcune delle funzionalità di sicurezza di GKE Enterprise attraverso le seguenti attività:

• Applica TLS reciproca (mTLS) nella tua rete mesh di servizi utilizzando Config Sync per garantire una comunicazione sicura end-to-end.

• Configura un sistema di protezione della sicurezza che garantisca che i pod con container privilegiati non vengano implementati inavvertitamente utilizzando Policy Controller.

Costi

Il deployment dell'applicazione Bank of Anthos comporta costi pay-as-you-go per GKE Enterprise su Google Cloud , come indicato nella nostra pagina dei prezzi, a meno che tu non abbia già acquistato un abbonamento.

Sei anche responsabile di altri Google Cloud costi sostenuti durante l'esecuzione dell'applicazione Bank of Anthos, ad esempio gli addebiti per le VM Compute Engine e i bilanciatori del carico.

Ti consigliamo di eseguire la pulizia dopo aver completato il tutorial o esplorato il deployment per evitare ulteriori addebiti.

Prima di iniziare

Questo tutorial è il seguito del tutorial Explore Anthos. Prima di iniziare questo tutorial, segui le istruzioni riportate in quella pagina per configurare il progetto e installare il deployment di esempio di Anthos.

Configurazione dell'ambiente Cloud Shell

In questo tutorial utilizzerai la riga di comando di Cloud Shell e l'editor per apportare modifiche alla configurazione del cluster.

Per inizializzare l'ambiente shell per il tutorial, Anthos Sample Deployment fornisce uno script che esegue le seguenti operazioni:

• Installa gli strumenti a riga di comando mancanti per lavorare in modo interattivo con il deployment e verificare le modifiche apportate:

  • kubectl
  • kubectx
  • istioctl
  • nomos

• Imposta il contesto Kubernetes per anthos-sample-cluster1

• Clona il repository utilizzato da Config Sync per sincronizzare le modifiche alla configurazione con il cluster. Le modifiche che commit e push nel repository upstream vengono sincronizzate con la tua infrastruttura da Config Sync. Questa è la best practice consigliata per applicare le modifiche alla tua infrastruttura.

Per configurare l'ambiente:

1. Assicurati di avere una sessione Cloud Shell attiva. Puoi avviare Cloud Shell facendo clic su Attiva Cloud Shell dalla consoleGoogle Cloud nel progetto del tutorial.

2. Crea una directory in cui lavorare:

   mkdir tutorial
   cd tutorial
   

3. Scarica lo script di inizializzazione:

   curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
   

4. Inserisci lo script di inizializzazione nel tuo ambiente Cloud Shell:

   source init-anthos-sample-deployment.env
   

   Output:

   /google/google-cloud-sdk/bin/gcloud
   /google/google-cloud-sdk/bin/kubectl
   Your active configuration is: [cloudshell-13605]
   export PROJECT as anthos-launch-demo-1
   export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for anthos-sample-cluster1.
   Copying gs://config-management-release/released/latest/linux_amd64/nomos...
   \ [1 files][ 40.9 MiB/ 40.9 MiB]
   Operation completed over 1 objects/40.9 MiB.
   Installed nomos into ~/bin.
   Cloned ACM config repo: ./anthos-sample-deployment-config-repo
   

5. Passa alla directory del repository di configurazione e utilizzala come directory di lavoro per il resto di questo tutorial:

   cd anthos-sample-deployment-config-repo
   

Applicare mTLS nella rete mesh di servizi

In previsione dell'espansione globale, il tuo CIO ha stabilito che tutti i dati utente devono essere criptati in transito per salvaguardare le informazioni sensibili in conformità alle leggi regionali sulla privacy e sulla crittografia dei dati.

Quindi, tutto il tuo traffico è attualmente sicuro?

1. Vai alla pagina Cloud Service Mesh nel tuo progetto in cui è stato eseguito il deployment di Anthos Sample Deployment:

   Vai alla pagina Cloud Service Mesh

2. Fai clic su transactionhistory nell'elenco dei servizi. Come hai visto in Esplora GKE Enterprise, la pagina dei dettagli del servizio mostra tutta la telemetria disponibile per il servizio.

3. Nella pagina transactionhistory, nel menu Navigazione, seleziona Servizi connessi. Qui puoi vedere le connessioni in entrata e in uscita per il servizio. Unicona lucchetto sbloccato indica che su questa porta è stato osservato traffico non criptato, che utilizza TLS (mTLS) reciproco.

mTLS è un protocollo di sicurezza che garantisce che il traffico sia sicuro e attendibile in entrambe le direzioni tra due servizi. Ogni servizio accetta solo traffico criptato da servizi autenticati. Come puoi vedere, Cloud Service Mesh mostra chiaramente che hai traffico non criptato nella mesh. In Cloud Service Mesh vengono utilizzati colori diversi per indicare se il traffico non criptato presenta un mix di testo non criptato e mTLS (arancione) o solo testo non criptato (rosso).

Con GKE Enterprise, ti bastano pochi passaggi per essere in conformità. Anziché apportare modifiche a livello di codice sorgente e ricompilare ed eseguire nuovamente il deployment dell'applicazione per risolvere il problema, puoi applicare la nuova norma di crittografia in modo dichiarativo tramite la configurazione utilizzando Config Sync per eseguire automaticamente il deployment della nuova configurazione da un repository Git centrale.

In questa sezione, imparerai a:

1. Modifica la configurazione dei criteri nel repository Git per imporre che i servizi utilizzino comunicazioni criptate tramite mTLS.

2. Affidati a Config Sync per rilevare automaticamente la modifica della policy dal repository e modificare la policy Cloud Service Mesh.

3. Verifica che la modifica del criterio sia stata apportata al cluster configurato per la sincronizzazione con il repository.

Conferma la configurazione di Config Sync

1. Il comando nomos è uno strumento a riga di comando che ti consente di interagire con l'operatore Config Management e svolgere altre utili attività di Config Sync dalla tua macchina locale o da Cloud Shell. Per verificare che Config Sync sia installato e configurato correttamente sul tuo cluster, esegui nomos status:

   nomos status
   

   Output:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
   

   L'output conferma che Config Sync è configurato per sincronizzare il cluster con il ramo master del repository di configurazione. L'asterisco nella prima colonna indica che il contesto corrente è impostato su anthos-sample-cluster1. Se non vedi questa opzione, passa al contesto attuale anthos-sample-cluster1:

   kubectl config use-context anthos-sample-cluster1
   

   Output:

   Switched to context "anthos-sample-cluster1".
   

2. Assicurati di trovarti nel ramo master:

   git checkout master
   

   Output:

   Already on 'master'
   Your branch is up to date with 'origin/master'.
   

3. Verifica il repository di configurazione upstream:

   git remote -v
   

   Output:

   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
   

4. Assicurati di trovarti ancora nella directory anthos-sample-deployment-config-repo ed esegui il seguente comando per controllare la configurazione di Git. Questa funzione helper viene inserita nel tuo ambiente dallo script di inizializzazione ed esegue i comandi git config per controllare i valori esistenti di user.email e user.name nella configurazione di Git. Se questi valori non sono configurati, la funzione imposta i valori predefiniti a livello di repository in base all'account Google Cloud attualmente attivo.

   init_git
   

   Output (esempio):

   Configured local git user.email to [e-mail]
   Configured local git user.name to user
   

Ora puoi eseguire il commit delle modifiche alle norme nel repository. Quando esegui il push di questi commit nel repository upstream (origine), Config Sync garantisce che queste modifiche vengano applicate al cluster che hai configurato per la gestione.

Aggiorna una policy per criptare tutto il traffico di servizio

La configurazione per Cloud Service Mesh viene specificata in modo dichiarativo utilizzando i file YAML. Per criptare tutto il traffico di servizio, devi modificare sia il file YAML che specifica i tipi di traffico che i servizi possono accettare, sia il file YAML che specifica il tipo di traffico che i servizi inviano a destinazioni specifiche.

1. Il primo file YAML da esaminare è namespaces/istio-system/peer-authentication.yaml, che è un criterio di autenticazione a livello di mesh che specifica i tipi di traffico che tutti i servizi nella mesh accettano per impostazione predefinita.

   cat namespaces/istio-system/peer-authentication.yaml
   

   Output:

   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: PERMISSIVE
   

   Come puoi vedere, la modalità mTLS PeerAuthentication è PERMISSIVE, il che significa che i servizi accettano sia il traffico HTTP in testo normale che mTLS.

2. Modifica namespaces/istio-system/peer-authentication.yaml per consentire solo la comunicazione criptata tra i servizi impostando la modalità mTLS su STRICT:

   cat <<EOF> namespaces/istio-system/peer-authentication.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

3. Successivamente, esamina la regola di destinazione in namespaces/istio-system/destination-rule.yaml. Specifica le regole per l'invio del traffico a destinazioni specifiche, incluso se il traffico è criptato. Tieni presente che TLSmode è DISABLE, il che significa che il traffico viene inviato in testo normale a tutti gli host corrispondenti.

   cat namespaces/istio-system/destination-rule.yaml
   

   Output:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

4. Modifica namespaces/istio-system/destination-rule.yaml in modo che Istio imposti un criterio di traffico che abiliti TLS per tutti gli host corrispondenti nel cluster utilizzando TLSmode ISTIO_MUTUAL:

   cat <<EOF> namespaces/istio-system/destination-rule.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

Esegui il push delle modifiche al repository

Sei quasi pronto a eseguire il push delle modifiche alla configurazione, ma ti consigliamo di eseguire alcuni controlli prima di eseguire il commit definitivo degli aggiornamenti.

1. Esegui nomos vet per assicurarti che la configurazione sia valida:

   nomos vet
   

   Nessun output indica che non sono stati rilevati errori di convalida.

2. Non appena esegui il push delle modifiche, Config Sync le rileva e le applica al sistema. Per evitare risultati imprevisti, ti consigliamo di verificare che lo stato live attuale della configurazione non sia cambiato da quando hai apportato le modifiche. Utilizza kubectl per verificare che destinationrule indichi che mTLS è disattivato per il cluster:

   kubectl get destinationrule default -n istio-system -o yaml
   

   Output:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   ...
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

3. Ora esegui il commit e il push di queste modifiche nel repository upstream. Il seguente comando utilizza una funzione helper chiamata watchmtls che è stata inserita nel tuo ambiente dallo script init. Questa funzione helper esegue una combinazione di nomos status e del comando kubectl che hai provato in precedenza. Monitora il cluster per rilevare le modifiche finché non premi Ctrl+C per uscire. Monitora il display finché non vedi che le modifiche sono state applicate e sincronizzate sul cluster.

   git commit -am "enable mtls"
   git push origin master && watchmtls
   

   Puoi anche visualizzare le modifiche nelle pagine di Cloud Service Mesh in GKE Enterprise.

   Vai alla pagina Cloud Service Mesh

   Dovresti vedere che licona lucchetto rosso aperto è cambiata. L'icona del lucchetto appare arancione (traffico misto) anziché verde (traffico interamente criptato) perché per impostazione predefinita esaminiamo l'ultima ora con un mix di mTLS e testo normale. Se controlli di nuovo dopo un'ora, dovresti vedere un lucchetto verde che indica che hai criptato correttamente tutto il traffico del servizio.

Utilizzo di Policy Controller per configurare i guardrail

Il tuo team di sicurezza è preoccupato per i potenziali attacchi root che potrebbero verificarsi quando esegui pod con container con privilegi (container con accesso root). Sebbene la configurazione attuale non implementi container privilegiati, è consigliabile proteggersi dal maggior numero possibile di vettori di minaccia che potrebbero compromettere le prestazioni o, peggio ancora, i dati dei clienti.

Nonostante l'impegno del team, esiste comunque il rischio che tu possa trovarti vulnerabile ad attacchi root involontari a causa di futuri aggiornamenti della configurazione tramite il processo di continuous delivery. Decidi di impostare una misura di protezione per proteggerti da questo pericolo.

Applicare barriere di sicurezza

I guardrail sono controlli amministrativi automatizzati destinati a far rispettare le norme che proteggono il tuo ambiente. Policy Controller include il supporto per la definizione e l'applicazione di regole personalizzate non coperte dagli oggetti Kubernetes nativi. Policy Controller controlla, verifica e applica le misure di protezione che applichi e che corrispondono ai requisiti unici di sicurezza, conformità normativa e governance della tua organizzazione.

Utilizzare Policy Controller

Policy Controller è basato su un motore di criteri open source chiamato Gatekeeper, che viene utilizzato per applicare i criteri ogni volta che una risorsa nel cluster viene creata, aggiornata o eliminata. Questi criteri sono definiti utilizzando vincoli della libreria di modelli di Policy Controller o di altri modelli di vincolo Gatekeeper.

Il deployment di esempio di Anthos su Google Cloud ha già Policy Controller installato e anche la libreria di modelli di Policy Controller è abilitata. Puoi sfruttare questa funzionalità quando implementi il guardrail utilizzando un vincolo esistente per i container privilegiati della libreria.

Applica un vincolo di policy per i container privilegiati

Per rispondere alle preoccupazioni del tuo team di sicurezza, applichi il vincolo K8sPSPPrivilegedContainer. Questo vincolo impedisce l'esecuzione di pod con container con privilegi.

1. Utilizzando il terminale Cloud Shell, crea un nuovo file constraint.yaml con il testo del vincolo della libreria, come segue:

   cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sPSPPrivilegedContainer
   metadata:
     name: psp-privileged-container
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pod"]
       excludedNamespaces: ["kube-system"]
   EOF
   

2. Utilizza nomos vet per verificare che la configurazione aggiornata sia valida prima di applicarla.

   nomos vet
   

   Il comando viene restituito in modalità silenziosa finché non si verificano errori.

3. Esegui il commit e il push delle modifiche per applicare il criterio. Puoi utilizzare nomos status con il comando watch per verificare che le modifiche vengano applicate al tuo cluster. Premi Ctrl+C per uscire dal comando dello smartwatch al termine.

   git add .
   git commit -m "add policy constraint for privileged containers"
   git push && watch nomos status
   

   Output:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy
   

Testare la policy

Dopo aver applicato il criterio, puoi testarlo tentando di eseguire un pod con un container privilegiato.

1. Nel terminale Cloud Shell, utilizza il seguente comando per creare un nuovo file nella directory del tutorial, nginx-privileged.yaml, con i contenuti di questa specifica di esempio:

   cat <<EOF> ~/tutorial/nginx-privileged.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged-disallowed
     labels:
       app: nginx-privileged
   spec:
     containers:
     - name: nginx
       image: nginx
       securityContext:
         privileged: true
   EOF
   

2. Prova ad avviare il pod con kubectl apply.

   kubectl apply -f ~/tutorial/nginx-privileged.yaml
   

   Output:

   Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
   Context: {"privileged": true}
   

   L'errore mostra che il controller di ammissione Gatekeeper che monitora il tuo ambiente Kubernetes ha applicato i nuovi criteri. Ha impedito l'esecuzione del pod a causa della presenza di un container con privilegi nella specifica del pod.

Il concetto di criteri controllati dalla versione che puoi applicare per configurare guardrail con Policy Controller è potente perché standardizza, unifica e centralizza la governance dei tuoi cluster, applicando i tuoi criteri tramite il monitoraggio attivo del tuo ambiente post-deployment.

Nel repository Gatekeeper puoi trovare molti altri tipi di criteri da utilizzare come misure di protezione per il tuo ambiente.

Esplorazione più approfondita del deployment

Questo tutorial ti ha mostrato come utilizzare alcune funzionalità di sicurezza di GKE Enterprise, ma c'è ancora molto da vedere e fare in GKE Enterprise con il nostro deployment. Puoi provare un altro tutorial o continuare a esplorare l'implementazione di esempio di Anthos su Google Cloud autonomamente, prima di seguire le istruzioni di pulizia nella sezione successiva.

Esegui la pulizia

Dopo aver terminato l'esplorazione dell'applicazione Bank of Anthos, puoi eliminare le risorse che hai creato su Google Cloud in modo che non occupino quota e non ti vengano addebitate in futuro.

• Opzione 1. Puoi eliminare il progetto. Tuttavia, se vuoi conservare il progetto, puoi utilizzare l'opzione 2 per eliminare il deployment.

• Opzione 2. Se vuoi mantenere il progetto attuale, puoi utilizzare terraform destroy per eliminare l'applicazione e il cluster di esempio.

Elimina il progetto (opzione 1)

Il modo più semplice per evitare la fatturazione è eliminare il progetto creato per questo tutorial.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina il deployment (opzione 2)

Questo approccio elimina l'applicazione Bank of Anthos e il cluster, ma non il progetto. Esegui questi comandi in Cloud Shell:

1. Passa alla directory che ospita gli script di installazione:

   cd bank-of-anthos/iac/tf-anthos-gke
   

2. Elimina il campione e il cluster:

   terraform destroy
   

3. Inserisci l'ID progetto quando richiesto.

Se prevedi di eseguire nuovamente il deployment, verifica che tutti i requisiti siano soddisfatti come descritto nella sezione Prima di iniziare.

Passaggi successivi

Nella documentazione di GKE Enterprise puoi trovare molte altre informazioni.

Prova altri tutorial

• Scopri di più sulla gestione dei servizi con il deployment di esempio di Anthos in Gestione dei servizi con GKE Enterprise.

• Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.

Scopri di più su GKE Enterprise

• Scopri di più su GKE Enterprise nella nostra panoramica tecnica.

• Scopri come configurare GKE Enterprise in un ambiente di produzione reale nella nostra guida alla configurazione.

• Scopri di più su come ottenere il massimo da Cloud Service Mesh nella documentazione di Cloud Service Mesh.

• Scopri di più su Policy Controller nella guida di Policy Controller.

• Scopri di più sulla gestione dichiarativa e centralizzata di configurazioni e policy nella documentazione di Config Sync e nella documentazione di Policy Controller.