Cloud Service Mesh tramite esempi: mTLS

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
   

   Tieni presente che frontend-external è un LoadBalancer e ha un indirizzo IP esterno. L'applicazione di esempio include un servizio che funge da bilanciatore del carico in modo da poter essere implementato 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 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 se hai eseguito il deployment del gateway di ingresso predefinito, il nome è istio-ingressgateway.
   • GATEWAY_NAMESPACE: lo 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
   

5. Apri un'altra scheda del browser e visita l'applicazione utilizzando l'indirizzo IP esterno del gateway di ingresso:

   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, 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 richiesta ha esito positivo con lo stato 200, perché per impostazione predefinita sono accettati sia il traffico TLS sia il traffico in testo normale.

Attivare l'autenticazione TLS reciproca per ogni spazio dei nomi

Applicchi 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 in YAML configura i servizi in modo che accettino solo mTLS. Per impostazione predefinita, mode è PERMISSIVE, il che configura i servizi in modo che accettino sia il testo non criptato sia 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. Vai alla scheda del browser che accede a Online Boutique utilizzando l'indirizzo IP esterno del servizio frontend-external:

   http://FRONTEND_EXTERNAL_IP/
   

4. Aggiorna la pagina. Il browser mostra il seguente errore:

   

   L'aggiornamento della pagina comporta l'invio di testo non cifrato al servizio frontend. A causa del criterio di autenticazione STRICT, il proxy sidecar blocca la 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 del gateway di ingresso esegue un handshake TLS con il proxy lato server (il servizio frontend in questo esempio). Questo handshake include uno scambio di certificati. Questi certificati vengono precaricati nei container proxy da Cloud Service Mesh.
   4. Il proxy del gateway in ingresso 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).

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

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

   Vai alla panoramica

2. Seleziona il progetto Google Cloud dall'elenco dei progetti nella barra dei menu.

3. Nella scheda Stato criterio, a seconda della configurazione, fai clic su Visualizza criterio o Attiva criterio. Viene visualizzata la dashboard di Policy Controller.

4. Fai clic sulla scheda Violazioni.

5. In Tipo di risorsa, seleziona la casella di controllo Pod. Viene visualizzato un elenco di pod che violano un criterio.

Trovare ed eliminare i criteri di autenticazione

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

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

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 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 ha esito positivo con lo stato 200, perché per impostazione predefinita sono accettati sia il traffico TLS sia il traffico in testo normale.

Se aggiorni la pagina della console Google Cloud che mostra l'elenco Carichi di lavoro, ora viene visualizzato lo stato mTLS Permissive.

Abilita TLS reciproco 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 il traffico mTLS in uscita verso un servizio. Per gestire questo comportamento, devi configurare una regola di destinazione.

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 alla boutique online utilizzando l'indirizzo IP esterno del servizio frontend-external e aggiorna la pagina. La pagina non viene visualizzata perché frontend service è impostato su STRICT mTLS e il proxy sidecar blocca la richiesta.

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

   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.

   

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
   

   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, il piano di controllo esegue automaticamente il provisioning dei certificati TLS in modo che i carichi di lavoro possano autenticarsi tra loro.

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

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

4. 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, vedrai che i dettagli di mTLS per tutti i servizi ora mostrano Permissive.