Questa pagina è stata tradotta dall'API Cloud Translation.

Tutorial: protezione di 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 ti introduce ad alcune delle potenti funzionalità di sicurezza di GKE Enterprise utilizzando Anthos Sample Deployment 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 per la sicurezza che garantisca che i pod con container con privilegi non vengono inavvertitamente implementati tramite Policy Controller.

Costi

Il deployment dell'applicazione Bank of Anthos ti comporta il 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 costi di Google Cloud 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 di Kubernetes per anthos-sample-cluster1
Clona il repository utilizzato da Config Sync sincronizzando le modifiche alla configurazione nel cluster. Modifiche che il commit e il push nel repository upstream siano sincronizzati dell'infrastruttura tramite 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 avvia 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

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

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 imposto che tutti i dati utente devono essere criptati in transito per salvaguardare le informazioni sensibili la conformità alle leggi regionali sulla privacy dei dati e sulla crittografia.

Quindi tutto il tuo traffico è attualmente protetto?

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

Vai alla pagina di 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 collegati. Qui puoi visualizzare sia In entrata che In uscita connessioni per il servizio. L'icona lucchetto sbloccato indica che alcune condizioni del traffico su questa porta che non utilizza TLS reciproco (mTLS).

mTLS è un protocollo di sicurezza che garantisce la sicurezza e l'affidabilità del traffico in entrambe le direzioni tra due i servizi di machine learning. Ogni servizio accetta solo traffico criptato dai servizi autenticati. Come puoi vedere, Cloud Service Mesh mostra chiaramente che nel tuo mesh è presente traffico non criptato. Diverso i colori vengono utilizzati in Cloud Service Mesh per indicare se il traffico non criptato include una combinazione di testo non crittografato e mTLS (arancione) o solo testo non crittografato (rosso).

Con GKE Enterprise, ti mancano solo pochi passaggi 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:

Modifica la configurazione dei criteri nel tuo repository Git per applicarlo e utilizzano le comunicazioni criptate tramite mTLS.
Affidati a Config Sync per il recupero automatico del criterio la modifica dal repository e regolare 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 Config Management l'operatore di telefonia mobile ed eseguire altre attività utili di Config Sync dal macchina locale o Cloud Shell. Per verificare che Config Sync sia correttamente installato e configurato sul 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, cambia la versione attuale contesto per anthos-sample-cluster1:
```
kubectl config use-context anthos-sample-cluster1
```
Output:
```
Switched to context "anthos-sample-cluster1".
```

Assicurati di trovarti 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 helper riceve il codice sorgente nel tuo ambiente dallo script di inizializzazione ed esegue git config per verificare gli elementi user.email esistenti della configurazione Git user.name valori. 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 è tutto pronto per eseguire il commit delle modifiche ai criteri nel tuo repository. Quando esegui push di questi commit nel repository a monte (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 file YAML. Per crittografare tutto il traffico dei servizi, devi modificare i file YAML che specificano i tipi di traffico che i servizi possono accettare e il codice YAML che specifica tipo di traffico che i servizi inviano a determinate destinazioni.

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, Ciò significa che i servizi accettano sia traffico in testo non crittografato, HTTP sia 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

Poi, controlla la colonna Destinazione Regola a namespaces/istio-system/destination-rule.yaml. Questo specifica le regole per l'invio del traffico verso le destinazioni specificate, tra cui 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 si sono verificati errori di convalida.
Non appena esegui il push delle modifiche, Config Sync le rileva e le applica al tuo 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 il fino a quando non viene visualizzato l'applicazione e la sincronizzazione delle modifiche nel cluster.
```
git commit -am "enable mtls"
git push origin master && watchmtls
```
Puoi anche vedere le modifiche riflesse nelle pagine Cloud Service Mesh in con GKE Enterprise.

Vai alla pagina di Cloud Service Mesh

Dovresti vedere che l'icona lucchetto di colore rosso sbloccato è cambiata. L'icona a forma di 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 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 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, i dati dei clienti.

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

Applicare i sistemi di protezione

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 verifica e applica i sistemi di protezione applicati e corrispondenti ai tuoi gli unici requisiti di sicurezza, conformità normativa e governance di un'organizzazione.

Utilizzare Policy Controller

Policy Controller è basato su un criterio open source chiamato Gatekeeper utilizzata per applicare i criteri ogni volta che una risorsa viene creato, aggiornato o eliminato. 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à Policy Controller installato e ha anche la libreria dei modelli di Policy Controller abilitata. Puoi prendere sfruttare questo aspetto quando implementi il sistema di protezione utilizzando un modello per i container 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 nega 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

Usa 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 usare nomos status con il comando watch per confermare che le modifiche sono state applicate ai tuoi in un cluster Kubernetes. Al termine, premi Ctrl+C per uscire dal comando dello smartwatch.

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 comando seguente per creare un nuovo file nel tutorial directory, nginx-privileged.yaml, con il contenuto 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

Tentativo di 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 nell'ambiente Kubernetes. Questo ha impedito a causa della presenza di un container con privilegi nel pod la specifica del container.

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

Puoi trovare molti altri tipi di criteri da utilizzare come guardrail per del tuo ambiente nel repository Gatekeeper.

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. Puoi provare un altro tutorial o continuare a esplorare personalmente il deployment di esempio di Anthos su Google Cloud. prima di seguire le istruzioni per la 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 usare l'opzione 2 per 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à 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 appspot.com URL, 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 elimina 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 vengono soddisfatte come descritto nella sezione Prima di iniziare.

Passaggi successivi

Scopri di più nella documentazione di GKE Enterprise.

Prova altri tutorial

Per saperne di più sulla gestione dei servizi con il deployment di esempio Anthos, vedi Gestire i servizi con GKE Enterprise.
Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.

Scopri di più su GKE Enterprise

Scopri di più su GKE Enterprise nel nostro panoramica tecnica.
Scopri come configurare GKE Enterprise in un ambiente di produzione reale nella nostra guida alla configurazione.
Scopri 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 dei criteri e sulla configurazione centralizzata e dichiarativa nella documentazione di Config Sync e nella documentazione di Policy Controller.