Cloud Service Mesh tramite esempi: mTLS

---

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio e non supporta le API Google Cloud. Per ulteriori informazioni, vedi Panoramica di Cloud Service Mesh.

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 server ha un file collaterale. Il sidecar client invia mTLS ai carichi di lavoro con sidecar e invia testo non cifrato ai carichi di lavoro senza sidecar. 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 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:

• GKE
• Cloud Service Mesh

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 maggiori 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 di Cloud Service Mesh gestito.
  • Esegui il deployment di un gateway di ingresso.
  • Deployment dell'applicazione di esempio Online Boutique dal repository anthos-service-mesh-packages, che viene modificato dall'insieme originale di manifest nel microservices-demo repository. Seguendo le best practice, ogni servizio viene disegnato in un ambito distinto con un account di servizio univoco.

• Crea un pod TestCurl per inviare traffico in testo non cifrato per i test.

    apiVersion: v1
    kind: Pod
    metadata:
      name: testcurl
      namespace: default
      annotations:
        sidecar.istio.io/inject: "false"
    spec:
      containers:
      - name: curl
        image: curlimages/curl
        command: ["sleep", "600"]
  

Accedere alla boutique online

1. 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 
   

2. Elenca i servizi nello spazio dei nomi frontend:

   kubectl get services -n frontend
   

   Nota che frontend-external è un LoadBalancer e ha un all'indirizzo IP esterno. L'applicazione di esempio include un servizio di bilanciamento del carico per poterne eseguire il deployment su GKE senza Cloud Service Mesh.

3. Visita l'applicazione nel browser utilizzando l'indirizzo IP esterno del Servizio frontend-external:

   http://FRONTEND_EXTERNAL_IP/
   

4. Cloud Service Mesh ti offre la possibilità di eseguire il deployment di un gateway in entrata. Puoi e accedere alla Boutique online utilizzando l'indirizzo IP esterno del server gateway VPN ad alta disponibilità. 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 se hai eseguito il deployment del gateway di ingresso 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
   

5. Apri un'altra scheda del browser e visita l'applicazione utilizzando la Indirizzo IP esterno del gateway in entrata:

   http://INGRESS_GATEWAY_EXTERNAL_IP/
   

6. 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, è necessario ricostruire il nome DNS del servizio frontend.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -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.

Attivare l'autenticazione TLS reciproca per ogni spazio dei nomi

Puoi applicare mTLS applicando un criterio PeerAuthentication con kubectl.

1. 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.

2. 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
   

   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

3. Nel browser, vai alla scheda di accesso a Boutique online utilizzando il indirizzo IP esterno del servizio frontend-external:

   http://FRONTEND_EXTERNAL_IP/
   

4. 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 del STRICTcriterio di autenticazione, il proxy sidecar blocca le richiesta al servizio.

5. 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:

   1. Il browser invia una richiesta HTTP in testo normale al server.
   2. Il container proxy del gateway di ingresso intercetta la richiesta.
   3. 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.
   4. 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.
   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).

6. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   La tua richiesta non va a buon fine poiché stiamo inviando traffico in testo non crittografato dal carico di lavoro senza sidecar dove viene applicato il criterio STRICT peerAuthentication.

Trovare ed eliminare i criteri di autenticazione

1. Per un elenco di tutti i criteri PeerAuthentication nel service mesh:

   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
   

2. Elimina il criterio di autenticazione da tutte le boutique online spazi dei nomi:

   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
   

3. Accedi alla boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina viene visualizzata come previsto.

4. Esegui il seguente comando per curl il servizio frontend con HTTP normale da un altro pod.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -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 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 determinato carico di lavoro, devi configurare la sezione selector e specificare 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.

1. 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
   

   Risultato previsto:

   peerauthentication.security.istio.io/frontend created

2. 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

3. 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.

4. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

   kubectl exec testcurl -n default -- 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é stiamo inviando traffico non criptato dal carico di lavoro senza sidecar in cui viene applicato il criterio peerAuthentication RIGOROSO.

5. Elimina il criterio di autenticazione:

   kubectl delete peerauthentication -n frontend frontend
   

   Risultato previsto:

   peerauthentication.security.istio.io "frontend" deleted
   

6. 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 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 tra loro.

1. 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

2. Accedi alla boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina non viene visualizzata.

3. Esegui questo comando per curl il servizio frontend con HTTP normale da un altro pod.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   La tua richiesta non va a buon fine poiché stiamo inviando traffico in testo non crittografato dal carico di lavoro senza sidecar dove viene applicato il criterio STRICT peerAuthentication.

4. Elimina il criterio mesh-wide:

   kubectl delete peerauthentication -n istio-system mesh-wide
   

   Output previsto:

   peerauthentication.security.istio.io "mesh-wide" deleted
   

Nota: per ulteriori informazioni sui criteri di autorizzazione, consulta Cloud Service Mesh con esempi: autorizzazione.

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:

  1. 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
  

  1. 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: