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:
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, eseguinomos 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 suanthos-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 comandigit config
per controllare i valoriuser.email
euser.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 suSTRICT
: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 TLSmodeISTIO_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 chedestinationrule
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 scriptinit
. Questa funzione di supporto esegue una combinazione dinomos status
e del comandokubectl
che hai provato in precedenza. Monitora il cluster per rilevare eventuali modifiche finché non premiCtrl+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 comandowatch
per verificare che le modifiche vengano applicate al cluster. PremiCtrl+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.
- In the Google Cloud console, go to the Manage resources page.
- 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.