In Cloud Service Mesh 1.5 e versioni successive, il protocollo TLS mutuale automatico (mTLS automatico) è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un sidecar. Il lato client invia mTLS ai carichi di lavoro con file collaterali e invia il testo non crittografato ai carichi di lavoro senza file collaterali. Tieni presente, tuttavia, che i servizi accettano sia il traffico in testo normale sia il traffico mTLS. Quando inietti i proxy sidecar nei tuoi pod, ti consigliamo di configurare anche i tuoi servizi in modo che accettino solo traffico mTLS.
Con Cloud Service Mesh, puoi applicare mTLS al di fuori del codice dell'applicazione, applicando un singolo file YAML. Cloud Service Mesh ti offre la flessibilità di applicare un criterio di autenticazione all'intero mesh di servizi, a uno spazio dei nomi o a un singolo carico di lavoro.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Al termine del tutorial, puoi evitare i costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.
Prima di iniziare
Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verifica che la fatturazione sia abilitata per il tuo progetto.
Installa Cloud Service Mesh su un cluster GKE e distribuisci un gateway di accesso. Se devi configurare un cluster per questo tutorial, consulta la guida rapida di Cloud Service Mesh, che illustra:
- Creazione di un cluster GKE.
- Esegue il provisioning di Cloud Service Mesh gestito.
- Deployment di un gateway in entrata.
- Il deployment dell'applicazione di esempio Online Boutique dall'
anthos-service-mesh-packages
un repository, che viene modificato rispetto all'insieme originale di manifestmicroservices-demo
un repository. Seguendo le best practice, il deployment di ogni servizio viene eseguito in uno spazio dei nomi separato con un account di servizio univoco.
Accedere alla boutique online
Imposta il contesto corrente per
kubectl
sul cluster in cui hai eseguito il deployment di Online Boutique:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Elenca i servizi nello spazio dei nomi
frontend
:kubectl get services -n frontend
Nota che
frontend-external
è unLoadBalancer
e ha un all'indirizzo IP esterno. L'applicazione di esempio include un servizio che è un bilanciatore del carico in modo che possa essere implementato su GKE senza Cloud Service Mesh.Visita l'applicazione nel browser utilizzando l'indirizzo IP esterno del Servizio
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Cloud Service Mesh ti offre la possibilità di eseguire il deployment di un gateway in entrata. Puoi anche accedere alla Boutique online utilizzando l'indirizzo IP esterno del gateway di ingresso. Ottieni l'IP esterno del gateway. Sostituisci i segnaposto con le seguenti informazioni:
- GATEWAY_SERVICE_NAME : il nome del gateway in entrata
completamente gestito di Google Cloud. Se hai eseguito il deployment del gateway di esempio senza modifiche o
hai eseguito il deployment
gateway in entrata predefinito,
il nome è
istio-ingressgateway
. - GATEWAY_NAMESPACE: il nome dello spazio dei nomi in cui hai disegnato il gateway di ingresso. Se hai implementato il gateway di ingresso predefinito, il nome dello spazio dei nomi è
istio-system
.
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
- GATEWAY_SERVICE_NAME : il nome del gateway in entrata
completamente gestito di Google Cloud. Se hai eseguito il deployment del gateway di esempio senza modifiche o
hai eseguito il deployment
gateway in entrata predefinito,
il nome è
Apri un'altra scheda del browser e visita l'applicazione utilizzando la Indirizzo IP esterno del gateway in entrata:
http://INGRESS_GATEWAY_EXTERNAL_IP/
Esegui il seguente comando per
curl
il serviziofrontend
con HTTP normale da un altro pod. Poiché i servizi si trovano in spazi dei nomi diversi, devi eseguire curl sul nome DNS del serviziofrontend
.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La richiesta va a buon fine con lo stato
200
, perché per impostazione predefinita sono accettati sia il traffico TLS sia il testo normale.
Attivare l'autenticazione TLS reciproca per ogni spazio dei nomi
Puoi applicare mTLS applicando un criterio PeerAuthentication
con kubectl
.
Salva il seguente criterio di autenticazione come
mtls-namespace.yaml
.cat <<EOF > mtls-namespace.yaml apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "namespace-policy" spec: mtls: mode: STRICT EOF
La riga
mode: STRICT
in YAML configura i servizi in modo che accettino solo mTLS. Per impostazione predefinita, il valoremode
èPERMISSIVE
e configura per accettare testo non crittografato e mTLS.Applica il criterio di autenticazione per configurare tutti i servizi di Online Boutique in modo che accettino solo mTLS:
for ns in ad cart checkout currency email frontend loadgenerator \ payment product-catalog recommendation shipping; do kubectl apply -n $ns -f mtls-namespace.yaml done
Output previsto:
peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created
Nel browser, vai alla scheda di accesso a Boutique online utilizzando il indirizzo IP esterno del servizio
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Aggiorna la pagina. Il browser visualizza il seguente errore:
L'aggiornamento della pagina causa l'invio del testo non crittografato al servizio
frontend
. A causa delSTRICT
criterio di autenticazione, il proxy sidecar blocca le richiesta al servizio.Vai alla scheda del browser che accede alla Boutique online utilizzando l'indirizzo IP esterno del
istio-ingressgateway
e aggiorna la pagina, che viene visualizzata correttamente. Quando accedi a Online Boutique utilizzando il gateway di ingresso, la richiesta segue il seguente percorso:Flusso di autenticazione mTLS:
- Il browser invia una richiesta HTTP in testo non crittografato al server.
- Il container proxy del gateway di ingresso intercetta la richiesta.
- Il proxy gateway in entrata esegue un handshake TLS con proxy lato server (il servizio frontend in questo esempio). Questo handshake prevede uno scambio di certificati. Questi certificati sono precaricati dei container proxy da Cloud Service Mesh.
- Il proxy del gateway in entrata esegue un controllo di denominazione sicuro sulla certificato del server, verificando che sia in esecuzione un'identità autorizzata il server.
- Il gateway di ingresso e i proxy server stabiliscono una connessione TLS mutuale e il proxy server inoltra la richiesta al contenitore dell'applicazione server (il servizio frontend).
Esegui il seguente comando per
curl
il serviziofrontend
con HTTP normale da un altro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La tua richiesta non va a buon fine perché tutti i servizi di Boutique online sono impostati su
STRICT
mTLS e il proxy sidecar blocca la richiesta a il servizio.Output previsto:
000 command terminated with exit code 56
Visualizzare lo stato di mTLS
Puoi visualizzare lo stato delle funzionalità di sicurezza di GKE Enterprise, inclusi i criteri di autenticazione, nella console Google Cloud.
Nella console Google Cloud, vai alla pagina Panoramica di GKE Enterprise.
Seleziona il progetto Google Cloud dall'elenco dei progetti nella barra dei menu.
Nella scheda Stato secondo le norme, a seconda della configurazione, fai clic su Visualizza criterio o Abilita criterio. Si apre la dashboard di Policy Controller.
Fai clic sulla scheda Violazioni.
In Tipo di risorsa, seleziona la casella di controllo Pod. Viene visualizzato un elenco di Pod che violano un criterio.
Trova ed elimina i criteri di autenticazione
Per un elenco di tutti i
PeerAuthentication
criteri nel mesh di servizi:kubectl get peerauthentication --all-namespaces
L'output è simile al seguente:
NAMESPACE NAME MODE AGE ad namespace-policy STRICT 17m cart namespace-policy STRICT 17m checkout namespace-policy STRICT 17m currency namespace-policy STRICT 17m email namespace-policy STRICT 17m frontend namespace-policy STRICT 17m loadgenerator namespace-policy STRICT 17m payment namespace-policy STRICT 17m product-catalog namespace-policy STRICT 17m recommendation namespace-policy STRICT 17m shipping namespace-policy STRICT 17m
Elimina il criterio di autenticazione da tutti gli spazi dei nomi di Boutique online:
for ns in ad cart checkout currency email frontend loadgenerator payment \ product-catalog recommendation shipping; do kubectl delete peerauthentication -n $ns namespace-policy done;
Risultato previsto:
peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted
Accedi alla boutique online utilizzando l'indirizzo IP esterno del servizio
frontend-external
e aggiorna la pagina. La pagina viene visualizzata come previsto.Esegui il seguente comando per
curl
il serviziofrontend
con HTTP normale da un altro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La richiesta va a buon fine con lo stato
200
, perché per impostazione predefinita sono accettati sia il traffico TLS sia il testo normale.
Se nella console Google Cloud aggiorni la pagina che mostra
Carichi di lavoro, ora mostra che lo stato mTLS è Permissive
.
Attivare l'autenticazione TLS reciproca per carico di lavoro
Per impostare un criterio PeerAuthentication
per un carico di lavoro specifico, devi configurare
sezione selector
e specifica le etichette corrispondenti al carico di lavoro desiderato.
Tuttavia, Cloud Service Mesh non può aggregare i criteri a livello di carico di lavoro per i messaggi in uscita
Traffico mTLS verso un servizio. Devi configurare una regola di destinazione per gestire
tale comportamento.
Applica un criterio di autenticazione a un determinato carico di lavoro. Nota come il seguente criterio utilizza etichette e selettori per scegliere come target lo specifico
frontend
e deployment continuo.cat <<EOF | kubectl apply -n frontend -f - apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "frontend" namespace: "frontend" spec: selector: matchLabels: app: frontend mtls: mode: STRICT EOF
Risultato previsto:
peerauthentication.security.istio.io/frontend created
Configura una regola di destinazione corrispondente.
cat <<EOF | kubectl apply -n frontend -f - apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "frontend" spec: host: "frontend.demo.svc.cluster.local" trafficPolicy: tls: mode: ISTIO_MUTUAL EOF
Risultato previsto:
destinationrule.networking.istio.io/frontend created
Accedi a Online Boutique utilizzando l'indirizzo IP esterno del
frontend-external
e aggiorna la pagina. La pagina non viene visualizzata perchéfrontend service
è impostato suSTRICT
mTLS e il proxy sidecar blocca la richiesta.Esegui il seguente comando per
curl
il serviziofrontend
con HTTP normale da un altro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La richiesta non va a buon fine con il codice di stato
56
.Se nella console Google Cloud aggiorni la pagina che mostra Carichi di lavoro, mostra ora che lo stato mTLS per Il servizio
frontend
èStrict
e tutti gli altri servizi sono impostati suPermissive
.Elimina il criterio di autenticazione:
kubectl delete peerauthentication -n frontend frontend
Output previsto:
peerauthentication.security.istio.io "frontend" deleted
Elimina la regola di destinazione:
kubectl delete destinationrule -n frontend frontend
Output previsto:
destinationrule.networking.istio.io "frontend" deleted
Applicazione di mTLS a livello di mesh
Per impedire a tutti i servizi nel mesh di accettare traffico di testo non crittografato, imposta
un criterio PeerAuthentication
a livello di mesh con la modalità mTLS impostata su STRICT
.
Il criterio PeerAuthentication
a livello di mesh non deve avere un selettore e deve essere
applicata nello spazio dei nomi principale, istio-system
. Quando esegui il deployment del criterio,
di controllo del piano di controllo esegue automaticamente il provisioning dei certificati TLS in modo che i carichi di lavoro
di autenticarsi reciprocamente.
Applica mTLS a livello di mesh:
kubectl apply -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "mesh-wide" namespace: "istio-system" spec: mtls: mode: STRICT EOF
Risultato previsto:
peerauthentication.security.istio.io/mesh-wide created
Accedi alla boutique online utilizzando l'indirizzo IP esterno del servizio
frontend-external
e aggiorna la pagina. La pagina non viene visualizzata.Esegui il seguente comando per
curl
il serviziofrontend
con HTTP normale da un altro pod.kubectl exec \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -c istio-proxy -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
La richiesta non va a buon fine con il codice di stato
56
.Elimina il criterio
mesh-wide
:kubectl delete peerauthentication -n istio-system mesh-wide
Risultato previsto:
peerauthentication.security.istio.io "mesh-wide" deleted
Se aggiorni la pagina nella console Google Cloud, noterai che I dettagli di
mTLS
per tutti i servizi ora mostranoPermissive
.
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Se vuoi evitare addebiti aggiuntivi, elimina il cluster:
gcloud container clusters delete CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Se vuoi conservare il cluster e rimuovere l'esempio di Boutique online:
- Elimina gli spazi dei nomi dell'applicazione:
kubectl delete -f online-boutique/kubernetes-manifests/namespaces
Output previsto:
namespace "ad" deleted namespace "cart" deleted namespace "checkout" deleted namespace "currency" deleted namespace "email" deleted namespace "frontend" deleted namespace "loadgenerator" deleted namespace "payment" deleted namespace "product-catalog" deleted namespace "recommendation" deleted namespace "shipping" deleted
- Elimina le voci di servizio:
kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
Output previsto:
serviceentry.networking.istio.io "allow-egress-googleapis" deleted serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
Passaggi successivi
- Per una guida generale sulla configurazione dei criteri
PeerAuthentication
, consulta Configurare la sicurezza del trasporto: