Cloud Service Mesh tramite esempi: autorizzazione


In questo tutorial scoprirai che cos'è l'autorizzazione e come attivarla con Cloud Service Mesh in un'applicazione di esempio per scoprire come attivare i criteri di autorizzazione per i tuoi microservizi. Dovrai creare un accesso da AuthorizationPolicy a DENY a un microservizio, quindi un accesso specifico da AuthorizationPolicy a ALLOW 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 puoi controllare le comunicazioni da carico di lavoro a 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 di rete, spesso le regole firewall basate su IP non sono adeguate per proteggere l'accesso tra i workload. Con Cloud Service Mesh, puoi impostare regole di autorizzazione per:

  • Controlla l'accesso ai carichi di lavoro all'interno del tuo mesh, da carico di lavoro a carico di lavoro o da utente finale a carico di lavoro
  • Definisci i criteri in modo ampio o granulare, a seconda delle tue esigenze.

Per una spiegazione dettagliata sulla configurazione di criteri e best practice, consulta Autorizzazione con Cloud Service Mesh.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Al termine di questo tutorial, puoi evitare costi ricorrenti eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Esegui il deployment di un gateway di ingresso

  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 gateway in entrata:

    kubectl create namespace asm-ingress
    
  3. Attiva lo spazio dei nomi per l'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.

    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 il seguente 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 già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

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

      kubectl -n istio-system get controlplanerevision
      

      L'output è simile al seguente:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Nell'output, il valore nella colonna NAME è l'etichetta di revisione corrispondente 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
      

    All'interno del cluster

    Consigliato:esegui il seguente 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 sulle revisioni: segui le istruzioni riportate di seguito:

    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 seguente comando, REVISION_LABEL è il valore dell'etichetta della 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
    

    Risultato 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 iniettare automaticamente i proxy Envoy. Segui i passaggi per attivare l'iniezione automatica di sidecar.

  4. Esegui il deployment dell'app di esempio, del VirtualService per il frontend e degli 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
    

Visualizzare i servizi

  1. Visualizza i pod nello spazio dei nomi onlineboutique:

    kubectl get pods -n onlineboutique
    

    Risultato 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 nei pod è stato inserito correttamente un proxy sidecar Envoy. Se dopo un paio di minuti non viene visualizzato 2/2, consulta la guida alla risoluzione dei problemi.

  2. Recupera 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 vedere il negozio Online Boutique nel browser.

    frontend della boutique online

Autorizzazione DenyAll per un carico di lavoro

Questa sezione aggiunge un AuthorizationPolicy per negare tutto il traffico in entrata al servizio di valute. AuthorizationPolicies funzionano 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 arrivo a un servizio.

  1. Applica un AuthorizationPolicy al 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 tuo gateway per visualizzare Online Boutique nel browser web. Dovresti visualizzare un errore di autorizzazione (Errore del servizio interno 500) da currency service.

    Errore 500 authz rbac

Osserva i log del proxy sidecar

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

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

    Risultato 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
    

    Risultato 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 dovresti visualizzare un messaggio enforced denied che indica che currencyservice è impostato per bloccare le richieste in entrata.

Consenti accesso limitato

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

In questa sezione, attiverai la capacità dei servizi frontend e checkout di comunicare con il servizio currency.

  1. Nel seguente file, verifica che un source.principal(client) specifico sia autorizzato ad 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 il criterio:

    kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
    
  2. Visita EXTERNAL-IP nel tuo browser web. Ora dovresti essere in grado di accedere alla boutique online.

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 continui per le 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 conservare il cluster e rimuovere l'esempio Online Boutique:

    1. Elimina gli spazi dei nomi dell'applicazione:

      kubectl delete namespace onlineboutique
      

      Risultato previsto:

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

      kubectl delete namespace asm-ingress
      

      Risultato previsto:

      amespace "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