Questa pagina è stata tradotta dall'API Cloud Translation.

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.

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 su 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 Esplora 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:
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:

Assicurati di avere una sessione Cloud Shell attiva. Puoi avviare Cloud Shell facendo clic su Attiva Cloud Shell dalla console Google Cloud nel progetto del tutorial.
Crea una directory in cui lavorare:
```
mkdir tutorial
cd tutorial
```

Scarica lo script di inizializzazione:

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

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

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 in conformità con le leggi regionali sulla crittografia e sulla privacy dei dati.

Quindi tutto il tuo traffico è attualmente protetto?

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
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.
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 ricostruzioni e 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:

Modifica la configurazione dei criteri nel tuo repository Git per imporre ai servizi di utilizzare le comunicazioni criptate tramite mTLS.
Utilizza Config Sync per rilevare automaticamente la modifica del criterio dal repository e modificare il criterio Cloud Service Mesh.
Verifica che la modifica del criterio sia avvenuta nel cluster configurato per la sincronizzazione con il repository.

Conferma la configurazione di Config Sync

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 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, imposta il contesto corrente su anthos-sample-cluster1:
```
kubectl config use-context anthos-sample-cluster1
```
Output:
```
Switched to context "anthos-sample-cluster1".
```

Assicurati di essere nel ramo master:

git checkout master

Output:

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

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)

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 user@example.com
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 per cui è configurato.

Aggiorna un criterio per criptare tutto il traffico del servizio

La configurazione di Cloud Service Mesh viene specificata in modo dichiarativo utilizzando 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.

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.

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

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

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.

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.
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
```
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 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). Anche se la configurazione attuale non esegue il deployment di 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 futuri aggiornamenti di configurazione 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 volti a 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 ai requisiti specifici 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.

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

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.

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 il criterio

Dopo aver applicato il criterio, puoi testarlo tentando di eseguire un pod con un contenitore con privilegi.

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

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 guardrail 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 esplorato 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 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 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à descritte 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.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
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:

Passa alla directory che ospita gli script di installazione:
```
cd bank-of-anthos/iac/tf-anthos-gke
```
Elimina il sample e il cluster:
```
terraform destroy
```
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.