Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Anthos Service Mesh tramite esempi: mTLS

In Anthos Service Mesh 1.5 e versioni successive, il TLS automatico (mTLS automatico) è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un file collaterale. Il client collaterale invia mTLS ai carichi di lavoro con sidecar e invia testo non crittografato ai carichi di lavoro senza sidecar. Tuttavia, tieni presente che i servizi accettano sia il traffico in testo non crittografato che il traffico mTLS. Quando inserisci i proxy sidecar nei tuoi pod, ti consigliamo anche di configurare i tuoi servizi in modo che accettino solo il traffico mTLS.

Con Anthos Service Mesh, puoi applicare mTLS, al di fuori del codice dell'applicazione, applicando un singolo file YAML. Anthos 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.

mTLS reciproco

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Al termine di questo tutorial, puoi evitare i costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prima di iniziare

Questo tutorial utilizza l'applicazione di esempio Online Boutique per dimostrare la configurazione di mTLS su un cluster GKE in cui è installato Anthos Service Mesh.

Se devi configurare un cluster GKE per questo tutorial, consulta la guida rapida di Anthos Service Mesh, che illustra come configurare un cluster, installare Anthos Service Mesh ed eseguire il deployment dell'esempio di Boutique online nello spazio dei nomi demo.
Se hai un cluster GKE su cui è installato Anthos Service Mesh, ma ti serve l'esempio, consulta Online Boutique, che ti illustrerà come eseguire il deployment dell'esempio nello spazio dei nomi demo.

Accedi a Boutique online

Imposta il contesto attuale per kubectl sul cluster in cui hai eseguito il deployment di Boutique Online:

gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

Ottieni un elenco dei servizi Boutique online:
```
kubectl get services -n demo
```
Nota che frontend-external è un LoadBalancer e ha un indirizzo IP esterno. L'applicazione di esempio include un servizio che è un bilanciatore del carico per poterne eseguire il deployment su GKE senza Anthos Service Mesh.
Visita l'applicazione nel browser utilizzando l'indirizzo IP esterno del servizio frontend-external:
```
http://FRONTEND_EXTERNAL_IP/
```
Anthos Service Mesh fornisce un gateway in entrata predefinito chiamato istio-ingressgateway. Puoi anche accedere a Online Boutique utilizzando l'indirizzo IP esterno di istio-ingressgateway. Ottieni l'IP esterno di istio-ingressgateway:
```
kubectl get service istio-ingressgateway -n istio-system
```
Apri un'altra scheda nel browser e visita l'applicazione utilizzando l'indirizzo IP esterno di istio-ingressgateway:
```
http://INGRESS_GATEWAY_EXTERNAL_IP/
```
Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod nello spazio dei nomi demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
La tua richiesta ha esito positivo con lo stato 200, perché per impostazione predefinita sono accettati sia il traffico TLS sia il traffico in testo non crittografato.

Abilita TLS reciproco per spazio dei nomi

Puoi forzare l'applicazione di mTLS applicando un criterio PeerAuthentication con kubectl.

Applica i seguenti criteri di autenticazione per configurare tutti i servizi nello spazio dei nomi demo in modo che accettino solo mTLS:
```
kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "namespace-policy"
  namespace: "demo"
spec:
  mtls:
    mode: STRICT
EOF
```
Output previsto:
```
peerauthentication.security.istio.io/namespace-policy created
```
La riga mode: STRICT nel codice YAML configura i servizi in modo che accettino solo mTLS. Per impostazione predefinita, mode è PERMISSIVE, che configura i servizi per accettare sia il testo non crittografato che mTLS.
Vai alla scheda del browser che consente di accedere a Online Boutique utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. Il browser visualizza il seguente errore:

Se aggiorni la pagina, il testo non crittografato viene inviato al servizio frontend. A causa del STRICTcriterio di autenticazione, il proxy sidecar blocca la richiesta al servizio.
Vai alla scheda del browser che consente di accedere a Online Boutique utilizzando l'indirizzo IP esterno di istio-ingressgateway e aggiorna la pagina, che viene visualizzata correttamente. Quando accedi a Online Boutique utilizzando istio-ingressgateway, la richiesta segue il percorso seguente:

Flusso di autenticazione mTLS:
1. Il browser invia una richiesta HTTP in testo non crittografato al server.
2. Il container proxy istio-ingressgateway intercetta la richiesta.
3. Il proxy istio-ingressgateway esegue un handshake TLS con il proxy lato server (il servizio di frontend in questo esempio). Questo handshake include uno scambio di certificati. Questi certificati sono precaricati nei container proxy da Anthos Service Mesh.
4. Il proxy istio-ingressgateway esegue un controllo della denominazione sicura sul certificato del server, verificando che il server sia in esecuzione da un'identità autorizzata.
5. Il server istio-ingressgateway e i proxy server stabiliscono una connessione TLS reciproca, mentre il proxy del server inoltra la richiesta al contenitore dell'applicazione server (il servizio frontend).
Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod nello spazio dei nomi demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
La tua richiesta non va a buon fine perché tutti i servizi nello spazio dei nomi demo sono impostati su mTLS STRICT e il proxy sidecar blocca la richiesta al servizio.

Output previsto:
```
000
command terminated with exit code 56
```

Visualizza lo stato di mTLS

Puoi visualizzare lo stato delle funzionalità di sicurezza di Anthos, inclusi i criteri di autenticazione, nella console Google Cloud.

Nella console Google Cloud, vai alla pagina Sicurezza di GKE Enterprise.

Vai a Sicurezza di GKE Enterprise
Seleziona il progetto Google Cloud dall'elenco a discesa nella barra dei menu.

Il riepilogo dei criteri mostra lo stato della sicurezza delle applicazioni, incluso mTLS.
Fai clic su Controllo dei criteri per visualizzare gli stati dei criteri dei carichi di lavoro per ciascun cluster e spazio dei nomi. La scheda Stato mTLS offre una panoramica. L'elenco Carichi di lavoro mostra lo stato mTLS di ciascun carico di lavoro.

Trovare ed eliminare i criteri di autenticazione

Per un elenco di tutti i criteri PeerAuthentication nel mesh di servizi:
```
kubectl get peerauthentication --all-namespaces
```

Elimina il criterio di autenticazione:

kubectl delete peerauthentication -n demo namespace-policy

Output previsto:

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 questo comando per curl il servizio frontend con HTTP normale da un altro pod nello spazio dei nomi demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
La tua richiesta ha esito positivo con lo stato 200, perché per impostazione predefinita sono accettati sia il traffico TLS sia il traffico in testo non crittografato.

Se nella console Google Cloud la pagina che mostra l'elenco Carichi di lavoro aggiorni la pagina, lo stato mTLS è Permissive.

Abilita TLS reciproco per carico di lavoro

Per impostare un criterio PeerAuthentication per un carico di lavoro specifico, devi configurare la sezione selector e specificare le etichette che corrispondono al carico di lavoro desiderato. Tuttavia, Anthos Service Mesh non può aggregare i criteri a livello di carico di lavoro per il traffico mTLS in uscita verso un servizio. Per gestire tale comportamento, devi configurare una regola di destinazione.

Applica un criterio di autenticazione a un carico di lavoro specifico nello spazio dei nomi demo. Osserva come il seguente criterio utilizza etichette e selettori per scegliere come target il deployment frontend specifico.

cat <<EOF | kubectl apply -n demo -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "frontend"
  namespace: "demo"
spec:
  selector:
    matchLabels:
      app: frontend
  mtls:
    mode: STRICT
EOF

Output previsto:

peerauthentication.security.istio.io/frontend created

Configura una regola di destinazione corrispondente.

cat <<EOF | kubectl apply -n demo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "frontend"
spec:
  host: "frontend.demo.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

Output previsto:

destinationrule.networking.istio.io/frontend created

Accedi alla Boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina non viene visualizzata perché il criterio frontend service è impostato su mTLS STRICT e il proxy sidecar blocca la richiesta.
Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod nello spazio dei nomi demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
La tua richiesta ha esito negativo con codice di stato 56.

Se nella console Google Cloud aggiorni la pagina che mostra l'elenco Carichi di lavoro, lo stato mTLS per il servizio frontend è Strict e tutti gli altri servizi sono impostati su Permissive.

Elimina il criterio di autenticazione e la regola di destinazione:

kubectl delete peerauthentication -n demo frontend
kubectl delete destinationrule -n demo frontend

Applicazione di mTLS a livello di mesh

Per impedire a tutti i servizi nel mesh di accettare il 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 applicato nello spazio dei nomi principale, istio-system. Quando esegui il deployment del criterio, il piano di controllo esegue automaticamente il provisioning dei certificati TLS in modo che i carichi di lavoro possano autenticarsi l'uno con l'altro.

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

Output 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 questo comando per curl il servizio frontend con HTTP normale da un altro pod nello spazio dei nomi demo.

kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'

La tua richiesta ha esito negativo con codice di stato 56.

Elimina il criterio mesh-wide:

kubectl delete peerauthentication -n istio-system mesh-wide

Se aggiorni la pagina nella console Google Cloud, vedrai che i dettagli mTLS per tutti i servizi ora mostrano Permissive.

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.

Per evitare addebiti aggiuntivi, elimina il cluster:

gcloud container clusters delete  CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

Se vuoi mantenere il cluster e rimuovere l'esempio di Boutique online:
```
kubectl delete namespaces demo
```

Passaggi successivi

Per una guida generale sulla configurazione dei criteri PeerAuthentication, consulta Configurazione della sicurezza del trasporto.