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
Assicurati che la fatturazione sia abilitata per il tuo progetto.
Esegui il provisioning di Anthos Service Mesh gestito su un cluster GKE. Esistono diversi metodi di configurazione supportati:
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
Imposta il contesto attuale per
kubectl
nel cluster:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Crea uno spazio dei nomi per il gateway in entrata:
kubectl create namespace asm-ingress
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
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"}'
Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente,
REVISION
è il valore dell'etichetta di revisioneistiod
che hai annotato nel passaggio precedente.kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION --overwrite
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
In caso contrario, imposta il contesto attuale per
kubectl
nel cluster:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Crea lo spazio dei nomi per l'applicazione di esempio:
kubectl create namespace onlineboutique
Etichetta lo spazio dei nomi
onlineboutique
per inserire automaticamente i proxy Envoy. Segui la procedura per attivare l'inserimento automatico dei file collaterali.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
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 colonnaREADY
. Questo indica che nei pod è stato inserito correttamente un proxy sidecar Envoy. Se2/2
non viene visualizzato dopo un paio di minuti, consulta la Guida alla risoluzione dei problemi.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
Visita l'indirizzo
EXTERNAL-IP
nel browser web. Nel browser dovrebbe essere visualizzato il negozio 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.
Applica un
AuthorizationPolicy
acurrencyservice
. Osserva la corrispondenza con l'etichettacurrencyservice
nel file YAML.kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
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) dacurrency service
.
Osserva i log proxy sidecar
Per capire cosa succede nel proxy sidecar, puoi esaminare i log nel pod.
Ottieni il nome del tuo pod
currencyservice
:CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
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
Utilizza
curl
per inviare traffico al tuoEXTERNAL_IP
e generare log:for i in {0..10}; do curl -s -I $FRONTEND_IP ; done
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
.
- Nel file seguente, controlla che uno specifico
source.principal
(client) è autorizzato ad accedere acurrencyservice
:
Applica le norme:
kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
- Visita la
EXTERNAL-IP
nel browser web. Ora dovresti essere in grado di accedere a Online Boutique.
Osserva i tuoi servizi nella UI di sicurezza di Anthos Service Mesh
Nella console Google Cloud, vai alla pagina Sicurezza di GKE Enterprise.
Nella pagina Sicurezza puoi aggiungere o attivare funzionalità per rendere sicuri i carichi di lavoro delle applicazioni. Per saperne di più, consulta l'articolo Monitoraggio della sicurezza del mesh. Seleziona la scheda Controllo criteri per visualizzare una panoramica dei tuoi carichi di lavoro.
Tieni presente che nella colonna Controllo accesso al servizio, solo
currencyservice
viene visualizzato come "Attivato". Fai clic su Attivato per visualizzare i dettagli diAuthorizationPolicy
.
Qui puoi visualizzare i AuthorizationPolicy
che hai applicato. Questo è utile per avere visibilità su tutte le applicazioni, soprattutto se ai carichi di lavoro è applicato un numero elevato di criteri.
Esplora l'interfaccia utente. Puoi visualizzare l'interazione tra i tuoi servizi ed è utile per visualizzare il comportamento di sicurezza. Questo è solo un semplice esempio dei vantaggi dei criteri quando proteggono i 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 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:
Elimina gli spazi dei nomi dell'applicazione:
kubectl delete namespace onlineboutique
Output previsto:
namespace "onlineboutique" deleted
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
- Per una guida generale sulla configurazione dei criteri
PeerAuthentication
, consulta Configurazione di Transport Security. - Migliora la strategia di sicurezza del tuo cluster e della tua applicazione con questo tutorial su come rafforzare la sicurezza della tua app con Anthos Service Mesh e Config Management.
- Esplora la dashboard per la sicurezza del tuo mesh con l'opzione Monitora la sicurezza del mesh.
- Approfondisci i criteri di autorizzazione con l'articolo Configurare le funzionalità avanzate dei criteri di autorizzazione.
- Acquisisci familiarità con le best practice per la sicurezza di Anthos Service Mesh.