Anthos Service Mesh con l'esempio: autorizzazione


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

Che cos'è l'autorizzazione?

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

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

  • Controlla l'accesso ai carichi di lavoro all'interno del tuo mesh, che può essere tra carichi di lavoro e carico di lavoro
  • Definisci in modo ampio o dettagliato i criteri in base alle tue esigenze. Per una spiegazione approfondita sulla configurazione dei criteri e delle best practice, consulta Autorizzazione con Anthos Service Mesh.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Al termine di questo tutorial, puoi evitare i costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, consulta 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 attuale per kubectl nel 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. Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dal tipo di Anthos Service Mesh (gestito o nel cluster):

    Gestito

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

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

    Questa etichetta corrisponde al canale di rilascio gestito di Anthos Service Mesh corrente per la versione di Anthos Service Mesh.

    Nel cluster

    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 è 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. In caso contrario, 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. Etichetta lo spazio dei nomi onlineboutique per inserire automaticamente i proxy Envoy. Segui la procedura per attivare l'inserimento automatico dei file collaterali.

  4. Esegui il deployment dell'app di esempio, di 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
    

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 la tua applicazione devono essere in esecuzione, con un 2/2 nella colonna READY. Questo indica che nei pod è stato inserito correttamente un proxy sidecar Envoy. Se 2/2 non viene visualizzato 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}' \
    )
    

    Vedrai 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. Nel browser dovrebbe essere visualizzato il negozio online.

    frontend boutique online

Autorizzazione NegaAll per un carico di lavoro

In questa sezione viene aggiunto un AuthorizationPolicy per negare tutto il traffico in entrata al servizio di valuta. AuthorizationPolicies trasforma AuthorizationPolicies in configurazioni leggibili da Envoy e applicale ai proxy collaterali. Questo consente al proxy Envoy di autorizzare o rifiutare le richieste in arrivo a un servizio.

  1. Applica un AuthorizationPolicy a currencyservice. Osserva 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 all'EXTERNAL-IP del gateway per visualizzare Online Boutique nel browser web. Dovresti visualizzare un errore di autorizzazione (errore di servizio interno 500) da currency service.

    errore authz rbac 500

Osserva i log proxy sidecar

Per capire cosa succede nel proxy sidecar, puoi esaminare i log nel pod.

  1. Ottieni il nome del tuo 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 del 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 al tuo EXTERNAL_IP e 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) nel tuo proxy istio:

    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]
      ```
    

Dovresti vedere un messaggio enforced denied nei log, a indicare che currencyservice è impostato per bloccare le richieste in entrata.

Consenti accesso limitato

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

In questa sezione abiliterai al servizio frontend e checkout la possibilità di comunicare con il servizio currency.

  1. Nel file seguente, controlla che uno specifico source.principal(client) è 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"]

Applica le norme:

kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
  1. Visita la EXTERNAL-IP nel browser web. Ora dovresti essere in grado di accedere a Online Boutique.

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 aggiuntivi per le risorse utilizzate in questo tutorial, puoi eliminare il progetto o eliminare 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 del gateway Ingress:

      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