Stai visualizzando la documentazione legacy di Service Mesh della versione 1.19.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Ad esempio, Cloud Service Mesh: mTLS

In Cloud Service Mesh 1.5 e versioni successive, il protocollo TLS automatico reciproca (mTLS) è abilitato predefinito. 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. Tuttavia, tieni presente che i servizi accetta sia il traffico in testo non crittografato che il traffico mTLS. Man mano che inserisci proxy sidecar ai tuoi pod, ti consigliamo di configurare anche i servizi in modo che accettino solo traffico mTLS.

Con Cloud Service Mesh, puoi applicare mTLS al di fuori del codice dell'applicazione applicando un unico file YAML. Cloud Service Mesh ti offre la flessibilità di applicare un di autenticazione all'intero mesh di servizi, a uno spazio dei nomi o a un per ogni carico di lavoro.

mTLS reciproco

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. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine di questo tutorial, puoi evitare costi ricorrenti 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 ed esegui il deployment di un traffico in entrata gateway VPN ad alta disponibilità. Se devi configurare un cluster per questo tutorial, consulta guida rapida di Cloud Service Mesh, che ti guiderà attraverso:
- Creazione di un cluster GKE.
- Esegue il provisioning del mesh di servizi Cloud gestito.
- Esegui il deployment di un gateway di ingresso.
- Il deployment dell'applicazione di esempio Online Boutique dall' anthos-service-mesh-packages un repository, che viene modificato rispetto all'insieme originale di manifest microservices-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
```
Tieni presente che frontend-external è un LoadBalancer e ha un 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 consente di eseguire il deployment di un gateway di ingresso. 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 servizio gateway di ingresso. 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: lo spazio dei nomi in cui hai eseguito il deployment il gateway in entrata. Se hai implementato il gateway di ingresso predefinito, il nome dello spazio dei nomi è istio-system.
```
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
```
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 servizio frontend con HTTP normale da un altro pod. Poiché i servizi si trovano in spazi dei nomi diversi, devi eseguire curl sul nome DNS del servizio frontend.
```
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 ha esito positivo con lo stato 200 perché, per impostazione predefinita, sia TLS il traffico di testo normale sia accettato.

Abilita TLS reciproco per 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 nel file YAML configura i servizi solo accetta mTLS. Per impostazione predefinita, il valore mode è PERMISSIVE e configura per accettare testo non crittografato e mTLS.

Applica il criterio di autenticazione per configurare tutte le boutique online per accettare 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

Risultato 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

Vai alla scheda del browser che accede a Online Boutique utilizzando l'indirizzo IP esterno del servizio frontend-external:
```
http://FRONTEND_EXTERNAL_IP/
```
Aggiorna la pagina. Il browser mostra il seguente errore:

L'aggiornamento della pagina causa l'invio del testo non crittografato al servizio frontend. A causa del criterio di autenticazione STRICT, il proxy sidecar blocca la richiesta al servizio.
Nel browser, vai alla scheda di accesso a Boutique online utilizzando il indirizzo IP esterno di istio-ingressgateway e aggiorna la pagina, che viene visualizzato correttamente. Quando accedi a Online Boutique utilizzando il gateway di ingresso, la richiesta segue il seguente percorso:

Flusso di autenticazione mTLS:
1. Il browser invia una richiesta HTTP in testo normale al server.
2. Il container proxy del gateway in entrata intercetta la richiesta.
3. Il proxy del gateway di ingresso esegue un handshake TLS con il proxy lato server (il servizio frontend in questo esempio). Questo handshake prevede uno scambio di certificati. Questi certificati vengono precaricati nei container proxy da Cloud Service Mesh.
4. Il proxy del gateway in entrata esegue un controllo dei nomi sicuri sul certificato del server, verificando che il server sia in esecuzione con un'identità autorizzata.
5. 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 questo comando per curl il servizio frontend 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 perché tutti i servizi Online Boutique sono impostati su STRICT mTLS e il proxy sidecar blocca la richiesta al servizio.

Risultato 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 Panoramica di GKE Enterprise .

Vai alla panoramica
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 che violano un criterio.

Trovare ed eliminare i criteri di autenticazione

Per un elenco di tutti i criteri PeerAuthentication 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;

Output 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 questo comando per curl il servizio frontend 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 ha esito positivo con lo stato 200 perché, per impostazione predefinita, sia TLS il traffico di testo normale sia accettato.

Se aggiorni la pagina della console Google Cloud che mostra l'elenco dei carichi di lavoro, ora viene visualizzato 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 il traffico mTLS in uscita verso un servizio. Devi configurare una regola di destinazione per gestire questo comportamento.

Applica un criterio di autenticazione a un determinato carico di lavoro. Tieni presente che il seguente criterio utilizza etichette e selettori per scegliere come target la specifica implementazione frontend.

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

Output 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

Output 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 perché frontend service è impostato su STRICT mTLS e il proxy sidecar blocca la richiesta.
Esegui il seguente comando per curl il servizio frontend 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 e il codice di stato è 56.

Se aggiorni la pagina della console Google Cloud che mostra l'elenco dei carichi di lavoro, ora viene visualizzato lo stato mTLS per il servizio frontend Strict e tutti gli altri servizi sono impostati su Permissive.

Elimina il criterio di autenticazione:

kubectl delete peerauthentication -n frontend frontend

Risultato previsto:

peerauthentication.security.istio.io "frontend" deleted

Elimina la regola di destinazione:

kubectl delete destinationrule -n frontend frontend

Risultato 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 in testo non cifrato, 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, di controllo del piano di controllo esegue automaticamente il provisioning dei certificati TLS in modo che i carichi di lavoro di autenticarsi reciprocamente.

Applica il protocollo 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 display.

Esegui il seguente comando per curl il servizio frontend 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 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.

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 Online Boutique:

Elimina gli spazi dei nomi dell'applicazione:

kubectl delete -f online-boutique/kubernetes-manifests/namespaces

Risultato 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 del servizio:

kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml

Risultato 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: