Tutorial: proteggere GKE Enterprise

---

GKE Enterprise fornisce una piattaforma coerente per creare e fornire servizi sicuri, con funzionalità di sicurezza integrate a ogni livello che funzionano separatamente e insieme per fornire una difesa in profondità 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, un mesh di servizi e un'applicazione Bank of GKE Enterprise con più microservizi.

Nota: se non hai mai utilizzato GKE Enterprise e Anthos Sample Deployment, prima di provare questo tutorial, vai a Esplorare 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 reciproco (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 con privilegi non vengano implementati inavvertitamente utilizzando Policy Controller.

Costi

Il deployment dell'applicazione Bank of Anthos comporterà addebiti di pagamento a consumo per GKE Enterprise Google Cloud come indicato nella nostra pagina dei prezzi, a meno che tu non abbia già acquistato un abbonamento.

Sei inoltre 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 aver esplorato il deployment per evitare di incorrere in ulteriori addebiti.

Prima di iniziare

Questo tutorial fa seguito al tutorial Explore Anthos. Prima di iniziare questo tutorial, segui le istruzioni riportate nella 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 e l'editor di Cloud Shell per apportare modifiche alla configurazione del cluster.

Per inizializzare l'ambiente della 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 e verificare le modifiche al deployment:

  • 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 committi e invii al repository di origine vengono sincronizzate con la tua infrastruttura da Config Sync. Questa è la best practice consigliata per applicare modifiche all'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 del 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. Importa lo script di inizializzazione nell'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. Cambia la directory impostandola sul repository di configurazione e utilizzala come directory di lavoro per il resto del tutorial:

   cd anthos-sample-deployment-config-repo
   

Applicazione di mTLS nella rete mesh di servizi

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

Quindi tutto il tuo traffico è attualmente protetto?

1. Vai alla pagina Cloud Service Mesh nel progetto in cui hai eseguito il deployment del deployment di esempio di Anthos:

   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. Un'icona lucchetto sbloccato indica che su questa porta è stato osservato traffico che non 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 nel tuo mesh è presente traffico non criptato. In Cloud Service Mesh vengono utilizzati diversi colori per indicare se il traffico non criptato è composto da testo non criptato e mTLS (arancione) o solo da testo non criptato (rosso).

Con GKE Enterprise, ti mancano solo pochi passaggi per essere in conformità. Anziché apportare modifiche a livello di codice sorgente e rieseguire il deployment dell'applicazione per risolvere il problema, puoi applicare il nuovo criterio 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 tuo repository Git per imporre ai servizi di utilizzare comunicazioni criptate tramite mTLS.

2. Utilizza Config Sync per rilevare automaticamente la modifica del criterio dal repository e modificare il criterio Cloud Service Mesh.

3. Verifica che la modifica del criterio sia avvenuta nel 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 di gestione della configurazione e di eseguire altre utili attività di Config Sync dalla tua macchina locale o da Cloud Shell. Per verificare che Config Sync sia installato e configurato correttamente nel 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 tuo cluster con il ramo principale del repository di configurazione. L'asterisco nella prima colonna indica che il contesto corrente è impostato su anthos-sample-cluster1. Se non vedi questa opzione, imposta il contesto corrente su anthos-sample-cluster1:

   kubectl config use-context anthos-sample-cluster1
   

   Output:

   Switched to context "anthos-sample-cluster1".
   

2. Assicurati di essere 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 essere ancora nella directory anthos-sample-deployment-config-repo esegui il seguente comando per controllare la configurazione di Git. Questa funzione di supporto viene inserita nel tuo ambiente dallo script di inizializzazione ed esegue comandi git config per controllare i valori user.email e user.name esistenti della configurazione di Git. Se questi valori non sono configurati, la funzione imposta i valori predefiniti a livello di repo 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 ai criteri nel repository. Quando esegui 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 un criterio per criptare tutto il traffico del servizio

La configurazione di Cloud Service Mesh viene specificata in modo dichiarativo utilizzando i file YAML. Per criptare tutto il traffico del 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 invia 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 trafico accettati per impostazione predefinita da tutti i servizi nel mesh.

   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 di PeerAuthentication è PERMISSIVE, il che significa che i servizi accettano sia il traffico HTTP in testo non cifrato sia il traffico 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. Quindi, esamina la Regola di destinazione in namespaces/istio-system/destination-rule.yaml. Questo specifica le regole per l'invio di traffico alle destinazioni specificate, incluso se il traffico è criptato. Tieni presente che TLSmode è DISABLE, il che significa che il traffico viene inviato in testo non cifrato 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 nel repository

È quasi tutto pronto per inviare le modifiche alla configurazione. Tuttavia, ti consigliamo di eseguire alcuni controlli prima di eseguire il commit degli aggiornamenti.

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

   nomos vet
   

   L'assenza di output indica che non sono stati rilevati errori di convalida.

2. Non appena apporti le 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 rifletta la disattivazione di mTLS 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 principale. Il seguente comando utilizza una funzione di supporto chiamata watchmtls che è stata inserita nel tuo ambiente dallo script init. Questa funzione di supporto esegue una combinazione di nomos status e del comando kubectl che hai provato in precedenza. Monitora il cluster per rilevare eventuali modifiche finché non premi Ctrl+C per uscire. Monitora la visualizzazione 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 vedere le modifiche riflesse nelle pagine di Cloud Service Mesh in GKE Enterprise.

   Vai alla pagina Cloud Service Mesh

   Dovresti vedere che licona lucchetto rosso sbloccato è cambiata. L'icona lucchetto appare arancione (traffico misto) anziché verde (traffico interamente criptato) perché per impostazione predefinita esaminiamo l'ultima ora con una combinazione di mTLS e testo non cifrato. 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 team di sicurezza è preoccupato per i potenziali attacchi di root che potrebbero verificarsi durante l'esecuzione di pod con container con privilegi (container con accesso root). Sebbene la configurazione attuale non implementi contenitori con privilegi, è consigliabile difendersi da quanti più vettori di minacce possibili che potrebbero compromettere le prestazioni o, peggio ancora, i dati dei clienti.

Nonostante la diligenza del team, esiste comunque il rischio che tu possa trovarti vulnerabile a attacchi di root involontariamente a causa di aggiornamenti di configurazione futuri tramite il processo di distribuzione continua. Decidi di installare un parapetto di sicurezza per proteggerti da questo pericolo.

Applicare guardrail

I guardrail sono controlli amministrativi automatici progettati per applicare i criteri 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 i guardrail che applichi e che corrispondono alle specifiche esigenze 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 vengono definiti utilizzando i vincoli della libreria di modelli di Policy Controller o di altri modelli di vincolo di Gatekeeper.

Il deployment di esempio di Anthos su Google Cloud ha già installato Policy Controller e ha anche attivato la libreria di modelli di Policy Controller. Puoi sfruttare questa opportunità durante l'implementazione del guardrail utilizzando un vincolo esistente per i contenitori con privilegi della libreria.

Applicare una limitazione dei criteri per i container con privilegi

Per risolvere i problemi del team di sicurezza, applichi il vincolo K8sPSPPrivilegedContainer. Questo vincolo impedisce l'esecuzione dei 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 silenzio se 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 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
   

Testa la norma

Dopo aver applicato il criterio, puoi testarlo tentando di eseguire un pod con un contenitore 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 indica che il controller di ammissione Gatekeeper che monitora il tuo ambiente Kubernetes ha applicato il nuovo criterio. Ha impedito l'esecuzione del pod a causa della presenza di un contenitore con privilegi nella specifica del pod.

Il concetto di criteri con controllo della versione che puoi applicare per configurare i parapetti con Policy Controller è molto efficace perché standardizza, unifica e centralizza la governance dei tuoi cluster, applicando i tuoi criteri tramite il monitoraggio attivo dell'ambiente dopo il deployment.

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

Esplorare ulteriormente il deployment

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

Esegui la pulizia

Dopo aver terminato di esplorare l'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 corrente, 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 che hai 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à in questo documento, quando lo elimini elimini anche tutto il lavoro 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, il riuso dei progetti può aiutarti a non 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 i seguenti 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 sample 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

Scopri di più nella documentazione di GKE Enterprise.

Prova altri tutorial

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

• Esplora architetture di riferimento, diagrammi e best practice 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 come fare di più con 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 dei criteri e sulla configurazione centralizzata e dichiarativa nella documentazione di Config Sync e nella documentazione di Policy Controller.