Tutorial: Proteggere GKE Enterprise

GKE Enterprise fornisce una piattaforma coerente per la creazione e la distribuzione di 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 illustra 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 GKE Enterprise reale con un ambiente pratico e con un cluster GKE, un mesh di servizi e un'applicazione Bank of GKE Enterprise con più microservizi.

Obiettivi

In questo tutorial ti vengono presentate alcune funzionalità di sicurezza di GKE Enterprise tramite le seguenti attività:

  • Applica il protocollo TLS reciproco (mTLS) nel tuo mesh di servizi utilizzando Config Sync per garantire una comunicazione sicura end-to-end.

  • Configura un guardrail di sicurezza per garantire che i pod con container con privilegi non vengano distribuiti inavvertitamente tramite Policy Controller.

Costi

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

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

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

Prima di iniziare

Questo tutorial è un follow-up al tutorial di Explore Anthos. Prima di iniziare questo tutorial, segui le istruzioni nella pagina per configurare il tuo progetto e installare il deployment di esempio 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 shell per il tutorial, il deployment di esempio di Anthos fornisce uno script che:

  • 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 di cui esegui il commit e il push al repository upstream 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 di Cloud Shell attiva. Puoi avviare Cloud Shell facendo clic su Attiva Cloud Shell Pulsante Attiva shell dalla console Google 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. Origine dello 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. Cambia la directory impostandola sul repository di configurazione e utilizzala come directory di lavoro per il resto di questo tutorial:

    cd anthos-sample-deployment-config-repo

Applicazione di mTLS nel mesh di servizi

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

Quindi tutto il tuo traffico è attualmente al sicuro?

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

    Vai alla pagina Anthos 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 questo servizio.

  3. Nella pagina Cronologia delle transazioni, seleziona Servizi connessi nel menu di navigazione. Qui puoi vedere sia le connessioni In entrata che In uscita per il servizio. L'icona di un lucchetto sbloccato indica che parte del traffico è stato osservato su questa porta che non utilizza TLS reciproco (mTLS).

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 il traffico criptato dai servizi autenticati. Come puoi vedere, Anthos Service Mesh indica chiaramente che nella tua mesh è presente traffico non criptato. In Anthos Service Mesh vengono utilizzati colori diversi per indicare se il traffico non criptato include un mix di testo non crittografato e mTLS (arancione) o solo testo non crittografato (rosso).

Con GKE Enterprise, ti mancano solo pochi passaggi per raggiungere la conformità. Invece di apportare modifiche a livello di codice sorgente, nonché ricreare ed eseguire nuovamente il deployment dell'applicazione per risolvere questa situazione, 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 repository Git per fare in modo che i servizi utilizzino le comunicazioni criptate tramite mTLS.

  2. Affidati a Config Sync per rilevare automaticamente la modifica al criterio dal repository e regolare il criterio Anthos Service Mesh.

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

Conferma configurazione di Config Sync

  1. Il comando nomos è uno strumento a riga di comando che ti consente di interagire con l'operatore di Config Management ed eseguire altre attività utili di Config Sync dalla tua macchina locale o da Cloud Shell. Per verificare che Config Sync sia installato e configurato correttamente 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 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, cambia il contesto attuale in 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 ed esegui il comando seguente per verificare la configurazione di Git. Questa funzione helper viene acquisita nel tuo ambiente dallo script di inizializzazione ed esegue i comandi git config per verificare i valori user.email e user.name esistenti della configurazione 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 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 il push di questi commit nel repository upstream (origine), Config Sync assicura che le modifiche vengano applicate al cluster che l'hai configurato per gestire.

Aggiorna un criterio per criptare tutto il traffico dei servizi

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

  1. Il primo file YAML che devi esaminare è namespaces/istio-system/peer-authentication.yaml, un criterio di autenticazione a livello di mesh che specifica i tipi di traffico accettati per impostazione predefinita da tutti i servizi del tuo 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 traffico sia HTTP che mTLS in testo non crittografato.

  2. Modifica namespaces/istio-system/peer-authentication.yaml per consentire solo le comunicazioni criptate 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. Ora controlla la regola di destinazione in namespaces/istio-system/destination-rule.yaml. In questo modo vengono specificate le regole per l'invio del traffico alle destinazioni specificate, incluso se il traffico è criptato. Osserva che TLSmode è DISABLE, il che significa che il traffico viene inviato in testo non crittografato 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 per fare in modo che Istio imposti un criterio di traffico che abiliti TLS per tutti gli host corrispondenti nel cluster utilizzando la modalità TLS 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

È quasi tutto pronto per eseguire il push delle modifiche alla configurazione; tuttavia, ti consigliamo di eseguire alcuni controlli prima di confermare definitivamente gli aggiornamenti.

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

    nomos vet

    Nessun output indica che non si sono verificati errori di convalida.

  2. Non appena esegui il push delle modifiche, Config Sync le acquisisce e le applica al tuo sistema. Per evitare risultati imprevisti, ti consigliamo di verificare che l'attuale stato pubblicato della configurazione non sia cambiato dopo aver apportato le modifiche. Utilizza kubectl per verificare che destinationrule rifletta il fatto che mTLS è disabilitata 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 di queste modifiche ed eseguine il push nel repository upstream. Il seguente comando utilizza una funzione helper denominata watchmtls che è stata acquisita nel tuo ambiente dallo script init. Questa funzione helper esegue una combinazione di nomos status e del comando kubectl che hai provato in precedenza. Controlla il cluster per verificare le modifiche apportate fino a quando non premi Ctrl+C per uscire. Monitora il display finché non vedi che le modifiche vengono applicate e sincronizzate sul cluster.

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

    Le modifiche si rifletteranno anche sulle pagine Anthos Service Mesh in GKE Enterprise.

    Vai alla pagina Anthos Service Mesh

    Dovresti vedere che l'icona rossa a forma di lucchetto sbloccato è cambiata. L'icona lucchetto viene visualizzata in arancione (traffico misto) anziché in verde (traffico interamente criptato), perché per impostazione predefinita stiamo esaminando l'ultima ora con una combinazione di mTLS e testo non crittografato. Se ricontrolla dopo un'ora, dovresti vedere un lucchetto verde che indica che hai criptato tutto il traffico dei servizi.

Utilizzo di Policy Controller per configurare sistemi di protezione

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 esegua il deployment di container con privilegi, è consigliabile evitare il maggior numero possibile di vettori di minacce che potrebbero compromettere le prestazioni o, peggio ancora, i dati dei clienti.

Nonostante l'impegno del team, esiste ancora il rischio di vulnerabilità involontariamente in caso di attacchi rooting derivanti da futuri aggiornamenti della configurazione tramite il processo di distribuzione continua. Decidi di istituire un sistema di sicurezza per proteggerti da questo pericolo.

Applicare misure di protezione

Le guardrail sono controlli amministrativi automatizzati per applicare 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, controlla e applica i sistemi di protezione applicati in base agli specifici requisiti di sicurezza, conformità normativa e di governance della tua organizzazione.

Utilizzo di 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 del cluster viene creata, aggiornata o eliminata. Questi criteri vengono definiti utilizzando i vincoli della libreria dei modelli di Policy Controller o di altri modelli di vincoli Gatekeeper.

Nel deployment di esempio di Anthos su Google Cloud è già stato installato Policy Controller e è abilitata la libreria di modelli di Policy Controller. Puoi sfruttare questo aspetto durante l'implementazione del guardrail utilizzando un vincolo esistente per i container con privilegi della libreria.

Applica un vincolo del criterio per i container con privilegi

Per risolvere le preoccupazioni del tuo team di sicurezza, applica il vincolo K8sPSPPrivilegedContainer. Questo vincolo nega 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 di 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 restituisce automaticamente se non sono presenti errori.

  3. Esegui il commit delle modifiche ed eseguine il push per applicare il criterio. Puoi utilizzare nomos status con il comando watch per confermare che le modifiche vengano applicate al cluster. Al termine, premi Ctrl+C per uscire dal comando sullo 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 provando a eseguire un pod con un container con privilegi.

  1. Nel terminale Cloud Shell, utilizza il comando seguente per creare un nuovo file nella directory del tutorial, 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

  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 il nuovo criterio. Ha impedito l'esecuzione del pod a causa della presenza di un container con privilegi nella specifica del pod.

Il concetto di criteri con controllo della 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 attraverso il monitoraggio attivo dell'ambiente dopo il deployment.

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

Esplorare ulteriormente il 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. Prova un altro tutorial o continua a esplorare il deployment di esempio di Anthos su Google Cloud prima di seguire le istruzioni di pulizia riportate nella sezione successiva.

Esegui la pulizia

Dopo aver esplorato l'applicazione Bank of Anthos, puoi eseguire la pulizia delle risorse che hai creato su Google Cloud in modo che non occupino quota e non ti vengano addebitati costi in futuro.

  • Opzione 1. Puoi eliminare il progetto. Tuttavia, se vuoi mantenere 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.

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina il deployment (opzione 2)

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

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

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

  2. Elimina l'esempio 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

C'è molto altro da esplorare nella nostra documentazione di GKE Enterprise.

Prova altri tutorial

Scopri di più su GKE Enterprise