Versione 1.14

Anthos Service Mesh per esempio: Autorizzazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questo tutorial, imparerai che cos'è l'autorizzazione e come abilitarla con Anthos Service Mesh su un'applicazione di esempio per abilitare i criteri di autorizzazione ai tuoi microservizi. Creerai un accesso da AuthorizationPolicy a DENY per un microservizio e successivamente un accesso specifico da AuthorizationPolicy a ALLOW per un microservizio.

Che cos'è l'autorizzazione?

L'autenticazione verifica un'identità: questo servizio è chi dice di essere? L'autorizzazione verifica l'autorizzazione: questo servizio può farlo? L'identità è fondamentale per questa idea. Con Anthos Service Mesh, AuthorizationPolicies consente di controllare la comunicazione tra carichi di lavoro e di carico di lavoro nel tuo mesh per migliorare la sicurezza e l'accesso.

In un'architettura di microservizi, in cui le chiamate vengono effettuate oltre i confini della rete, spesso le regole firewall basate su IP tradizionali non sono sufficienti a garantire l'accesso tra i carichi di lavoro. Con Anthos Service Mesh, puoi impostare le regole di autorizzazione su:

  • Controlla l'accesso ai carichi di lavoro all'interno della tua rete mesh, dal carico di lavoro al carico di lavoro o dal carico di lavoro finale all'utente
  • Definire in modo ampio o granulare i criteri in base alle esigenze. Per una spiegazione approfondita sulla configurazione dei criteri e delle best practice, vedi Autorizzazione con Anthos Service Mesh.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

  • GKE
  • Anthos Service Mesh
  • Al termine di questo tutorial, puoi evitare costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

    Prima di iniziare

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

      gcloud container clusters get-credentials CLUSTER_NAME  \
      --project=PROJECT_ID \
      --zone=CLUSTER_LOCATION
      
    2. Crea uno spazio dei nomi per il tuo gateway in entrata:

      kubectl create namespace asm-ingress
      
    3. Abilita lo spazio dei nomi per l'iniezione. I passaggi dipendono dal tipo di Anthos Service Mesh (gestito o in-cluster):

      Gestita

      Applica l'etichetta di revisione di asm-managed allo spazio dei nomi:

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

      Questa etichetta corrisponde all'attuale canale di rilascio di Anthos Service Mesh gestito per la versione di Anthos Service Mesh.

      In-cluster

      1. Utilizza il seguente comando per individuare l'etichetta di 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 è il valore dell'etichetta di revisione istiod che hai annotato nel passaggio precedente.

        kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION --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 attuale per kubectl nel 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. Assegna un'etichetta allo spazio dei nomi onlineboutique per inserire automaticamente i proxy Envoy. Segui i passaggi per attivare l'iniezione automatica di sidecar.

    4. Esegui il deployment dell'app di esempio, VirtualService per il frontend e gli account di servizio per i carichi di lavoro. Per questo tutorial, eseguirai 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 dell'applicazione devono essere attivi e in esecuzione, mentre 2/2 nella colonna READY deve essere in esecuzione. Questo indica che i pod hanno un proxy sidecar Envoy inserito correttamente. Se non visualizzi 2/2 dopo un paio di minuti, 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}' \
      )
      

      L'output visualizzato è 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 vedere la boutique online nel tuo browser.

      frontend boutique online

    Autorizzazione NegaAll per un carico di lavoro

    Questa sezione aggiunge un AuthorizationPolicy per negare tutto il traffico in entrata al servizio di valuta. AuthorizationPolicies lavora trasformando AuthorizationPolicies in configurazioni leggibili da Envoy e applicando le configurazioni ai tuoi proxy sidecar. Questo consente al proxy Envoy di autorizzare o rifiutare le richieste in arrivo a un servizio.

    1. Applica un AuthorizationPolicy a currencyservice. Nota la corrispondenza sull'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 la boutique online nel browser web. Dovresti vedere un errore di autorizzazione (500 Internal Service Error) da currency service.

      Errore authz rbac 500

    Osserva i log del proxy sidecar

    Per vedere cosa succede 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 che consenta i log a livello di traccia. Per impostazione predefinita, le chiamate di autorizzazione bloccate non vengono registrate:

      kubectl exec -it $CURRENCY_POD -n onlineboutique -c istio-proxy -- curl -X POST "http://localhost:15000/logging?level=trace"
      

      Output previsto: 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 e generare i 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) nel tuo 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 il messaggio "Forzata il rifiuto" che indica che currencyservice è impostato per bloccare le richieste in entrata.

    Consenti accesso limitato

    Invece di un criterio DENYALL, puoi impostare l'accesso in modo che sia consentito per determinati carichi di lavoro. Questo sarà pertinente in un'architettura di microservizi in cui vuoi garantire che solo i servizi autorizzati possano comunicare tra loro.

    In questa sezione, consenti ai servizi frontend e checkout di comunicare con il servizio currency.

    1. Nel file seguente, controlla che un elemento source.principal(client) specifico sia inserito nella lista consentita per 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"]

    Applica il criterio:

    kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
    
    1. Visita l'indirizzo EXTERNAL-IP nel tuo browser web. Ora dovresti riuscire ad accedere a Boutique online.

    Osservare i servizi nell'interfaccia utente della sicurezza di Anthos Service Mesh

    1. Nella console Google Cloud, vai alla pagina Anthos Security.

      Vai alla sicurezza di Anthos

    2. Nella pagina Sicurezza puoi aggiungere o abilitare funzionalità per rendere sicuri i tuoi carichi di lavoro delle applicazioni. Per ulteriori informazioni, consulta la pagina Monitorare la sicurezza del mesh. Seleziona la scheda Controllo criteri per visualizzare una panoramica dei carichi di lavoro.

    3. Tieni presente che nella colonna Controllo dell'accesso ai servizi, viene mostrato solo currencyservice come "Attivato". Fai clic su Attivata per visualizzare i dettagli di AuthorizationPolicy.

      controllo dei criteri di sicurezza

    Qui puoi visualizzare l'AuthorizationPolicy che hai applicato. Ciò è utile per avere visibilità su tutte le tue applicazioni, in particolare se hai un numero elevato di criteri applicati ai carichi di lavoro. Esplora la UI. Puoi visualizzare i tuoi servizi che interagiscono tra loro ed è utile per visualizzare il comportamento di sicurezza. Questo è solo un semplice esempio dei vantaggi dei criteri durante la protezione dei carichi di lavoro.

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

    Elimina il progetto

    In Cloud Shell, elimina il progetto:

    gcloud projects delete PROJECT_ID
    

    Elimina le risorse

    • Se vuoi mantenere il cluster e rimuovere l'esempio di Boutique online:

      1. Elimina gli spazi dei nomi dell'applicazione:

        kubectl delete namespace onlineboutique
        

        Output previsto:

        namespace "onlineboutique" deleted
        
      2. Elimina lo spazio dei nomi di Ingress Gateway:

        kubectl delete namespace asm-ingress
        

        Output previsto:

        amespace "asm-ingress" deleted
        
    • Se vuoi evitare costi aggiuntivi, elimina il cluster:

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

    Passaggi successivi