Cloud Service Mesh tramite esempi: autorizzazione

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio e non supporta le API Google Cloud . Per saperne di più, consulta la panoramica di Cloud Service Mesh. .

In questo tutorial imparerai cos'è l'autorizzazione e come abilitarla con Cloud Service Mesh su un'applicazione di esempio per scoprire come abilitare le policy di autorizzazione per i microservizi. Creerai un AuthorizationPolicy per DENY l'accesso a un microservizio, quindi creerai un AuthorizationPolicy per ALLOW l'accesso specifico a un microservizio.

Che cos'è l'autorizzazione?

L'autenticazione verifica un'identità: questo servizio è chi dice di essere? L'autorizzazione verifica l'autorizzazione: questo servizio è autorizzato a farlo? L'identità è fondamentale per questa idea. Con Cloud Service Mesh, AuthorizationPolicies consente di controllare la comunicazione da workload a workload nel mesh per migliorare la sicurezza e l'accesso.

In un'architettura di microservizi, in cui le chiamate vengono effettuate attraverso i limiti di rete, le regole firewall basate su IP spesso non sono adeguate per proteggere l'accesso tra i workload. Con Cloud Service Mesh, puoi impostare regole di autorizzazione per:

• Controllare l'accesso ai workload all'interno del mesh, da workload a workload o da utente finale a workload
• Definire policy in modo ampio o granulare a seconda delle esigenze.

Per una spiegazione approfondita sulla configurazione delle policy e sulle best practice, consulta Autorizzazione con Cloud Service Mesh.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

• GKE
• Cloud Service Mesh

Al termine di questo tutorial, puoi evitare l'addebito di costi ricorrenti eliminando le risorse create. Per ulteriori informazioni, consulta Esegui la pulizia.

Prima di iniziare

• Assicurati che la fatturazione sia abilitata per il tuo progetto.

• Esegui il provisioning di Cloud Service Mesh su un cluster GKE. Sono disponibili vari metodi di configurazione supportati:

  • API Fleet e un control plane gestito su Google Cloud

  • asmcli e un control plane in-cluster non gestito su Google Cloud

• Clona il repository:

  git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
  cd anthos-service-mesh-samples
  

Esegui il deployment di un gateway in entrata

1. Imposta il contesto corrente per kubectl sul cluster:

   Nota: utilizza --region anziché --zone, se il cluster è un cluster regionale.

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

2. Crea uno spazio dei nomi per il gateway in entrata:

   kubectl create namespace asm-ingress
   

3. Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del control plane.

   Gestito (TD)

   Applica l'etichetta di inserimento predefinita allo spazio dei nomi:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Gestito (Istiod)

   Consigliato: esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Se sei un utente esistente con il control plane Istiod gestito: ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulla revisione. Segui queste istruzioni:

   1. Esegui questo comando per individuare i canali di rilascio disponibili:

      kubectl -n istio-system get controlplanerevision
      

      L'output è simile al seguente:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Nota: se nell'elenco precedente sono presenti due revisioni del control plane, rimuovine una. L'utilizzo di più canali del control plane nel cluster non è supportato.

      Nell'output, il valore nella colonna NAME è l'etichetta della revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.

   2. Applica l'etichetta di revisione allo spazio dei nomi:

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   Interno al cluster

   Consigliato: esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulla revisione: Segui queste istruzioni:

   1. Utilizza il comando seguente per individuare l'etichetta della revisione su istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
          jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente, REVISION_LABEL è il valore dell'etichetta di revisione istiod che hai annotato nel passaggio precedente.

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

4. Esegui il deployment del gateway di esempio nel repository anthos-service-mesh-samples:

   kubectl apply -n asm-ingress \
       -f docs/shared/asm-ingress-gateway
   

   Output previsto:

   serviceaccount/asm-ingressgateway configured
   service/asm-ingressgateway configured
   deployment.apps/asm-ingressgateway configured
   gateway.networking.istio.io/asm-ingressgateway configured
   

Deployment dell'applicazione di esempio Online Boutique

1. Se non l'hai ancora fatto, imposta il contesto corrente per kubectl sul cluster:

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

2. Crea lo spazio dei nomi per l'applicazione di esempio:

   kubectl create namespace onlineboutique
   

3. Etichetta lo spazio dei nomi onlineboutique per inserire automaticamente i proxy Envoy:

   kubectl label namespace onlineboutique \
      istio.io/rev- istio-injection=enabled --overwrite
   

4. Esegui il deployment dell'app di esempio, di VirtualService per il frontend e dei service account per i workload. Per questo tutorial, esegui il deployment di Online Boutique, un'app demo di microservizi.

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/virtual-service.yaml
   

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/service-accounts
   

Visualizza i tuoi servizi

1. Visualizza i pod nello spazio dei nomi onlineboutique:

   kubectl get pods -n onlineboutique
   

   Output previsto:

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-85598d856b-m84m6               2/2     Running   0          2m7s
   cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
   checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
   currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
   emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
   frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
   loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
   paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
   productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
   recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
   redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
   shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s
   

   Tutti i pod per l'applicazione devono essere attivi e in esecuzione, con un valore 2/2 nella colonna READY. Ciò indica che i pod hanno un proxy sidecar Envoy inserito correttamente. Se dopo qualche minuto non viene visualizzato 2/2, consulta la guida alla risoluzione dei problemi.

2. Ottieni l'IP esterno e impostalo su una variabile:

   kubectl get services -n asm-ingress
   export FRONTEND_IP=$(kubectl --namespace asm-ingress \
   get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
   )
   

   Viene visualizzato un output simile al seguente:

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
   asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m
   
   

3. Visita l'indirizzo EXTERNAL-IP nel browser web. Dovresti visualizzare il negozio Online Boutique nel browser.

   

Autorizzazione DenyAll per un workload

Questa sezione aggiunge un AuthorizationPolicy per negare tutto il traffico in entrata al servizio di valuta. AuthorizationPolicies funziona trasformando AuthorizationPolicies in configurazioni leggibili da Envoy e applicando le configurazioni ai proxy sidecar. In questo modo, il proxy Envoy può autorizzare o negare le richieste in entrata a un servizio.

1. Applica un AuthorizationPolicy a currencyservice. Nota la corrispondenza con l'etichetta currencyservice nel file YAML.

   kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
   

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: currency-policy
   spec:
     selector:
       matchLabels:
         app: currencyservice

2. Prova ad accedere a EXTERNAL-IP del gateway per visualizzare Online Boutique nel browser web. Dovresti visualizzare un errore di autorizzazione (500 Internal Service Error) da currency service.

   

Esamina i log del proxy sidecar

Per vedere cosa sta succedendo nel proxy sidecar, puoi esaminare i log nel pod.

1. Ottieni il nome del pod currencyservice:

   CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
   

2. Imposta il proxy Envoy in modo da consentire i log a livello di traccia. Per impostazione predefinita, le chiamate di autorizzazione bloccate non vengono registrate:

   kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"
   

   Output previsto: none {:.devsite-disable-click-to-copy} active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace

3. Utilizza curl per inviare traffico a EXTERNAL_IP per generare log:

   for i in {0..10}; do
   curl -s -I $FRONTEND_IP ; done
   

4. Visualizza i log relativi al controllo dell'accesso basato sui ruoli (RBAC) in istio-proxy:

   kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac
   

   Output previsto:

   2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
   2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
   2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
     ```
   

Nei log dovrebbe essere visualizzato un messaggio enforced denied, che indica che currencyservice è impostato per bloccare le richieste in entrata.

Consenti l'accesso limitato

Anziché una policy DENYALL, puoi impostare l'accesso in modo che sia consentito per determinati workload. Questo sarà pertinente in un'architettura di microservizi in cui vuoi assicurarti che solo i servizi autorizzati possano comunicare tra loro.

In questa sezione, abiliterai i servizi frontend e checkout alla comunicazione con il servizio currency.

1. Nel file seguente, vedi che a un source.principal(client) specifico è consentito accedere a currencyservice:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

1. Applica la policy:

   kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
   

2. Visita EXTERNAL-IP nel browser web, ora dovresti essere in grado di accedere a Online Boutique.

Libera spazio

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 che al tuo Google Cloud account vengano addebitati costi continui per le risorse utilizzate in questo tutorial, puoi eliminare il progetto o eliminare le singole risorse.

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per questo tutorial, quando lo elimini, elimini anche qualsiasi altro lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

In Cloud Shell, elimina il progetto:

  gcloud projects delete PROJECT_ID

Elimina le risorse

• Se vuoi conservare il cluster e rimuovere l'esempio Online Boutique:

  1. Elimina gli spazi dei nomi dell'applicazione:

     kubectl delete namespace onlineboutique
     

     Output previsto:

     namespace "onlineboutique" deleted
     

  2. Elimina lo spazio dei nomi del gateway in entrata:

     kubectl delete namespace asm-ingress
     

     Output previsto:

     namespace "asm-ingress" deleted
     

• Se vuoi evitare addebiti aggiuntivi, elimina il cluster:

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

Passaggi successivi

• Per una guida generale alla configurazione delle policy PeerAuthentication, consulta Configurazione della sicurezza del trasporto.
• Esplora la dashboard per la sicurezza del mesh con Monitora la sicurezza del mesh.
• Approfondisci le policy di autorizzazione con Configurazione delle funzionalità avanzate dei criteri di autorizzazione.
• Acquisisci familiarità con le best practice per la sicurezza di Cloud Service Mesh.