Configurazione dei criteri di audit per i tuoi servizi
Un criterio di controllo ti consente di controllare l'accesso ai dati ai tuoi servizi in Cloud Service Mesh. Il controllo dei tuoi servizi ti aiuta a rispondere alle domande su "chi ha fatto cosa, quando e forse perché". Con un criterio di audit, puoi specificare quando un log di controllo e il contenuto dei log. Questa guida spiega come installare Cloud Service Mesh per poter usare un criterio di controllo.
Poiché visualizzi gli audit log nella Cloud Logging Esplora log nella console Google Cloud, controllo sono supportati solo sulle seguenti piattaforme:
- GKE su Google Cloud
- Google Distributed Cloud
- Google Distributed Cloud
Un criterio di controllo estende
AuthorizationPolicy
aggiungendo un'azione AUDIT
. Viene applicato solo nell'ambito delle norme di destinazione
(che può essere un carico di lavoro, uno spazio dei nomi o l'intero mesh). Le norme sono
ORed
insieme, ovvero viene registrata una richiesta se un criterio lo richiede. Se non viene eseguito alcun controllo
si applicano a un determinato carico di lavoro, per quel carico non viene generato alcun audit log.
Ecco un esempio di criterio di audit per controllare tutti gli accessi in scrittura a
Percorso /user/profile/*
in myapi
:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: ns1
name: anyname
spec:
selector:
matchLabels:
app: myapi
action: AUDIT
rules:
- to:
- operation:
methods: ["POST", "UPDATE", "DELETE"]
paths: ["/user/profile/*"]
Limitazioni
- Non è presente alcun audit log sul gateway in entrata.
- I contenuti del controllo non sono configurabili.
- Attualmente, gli audit log di Cloud Service Mesh hanno la stessa proprietà di affidabilità come normali log di accesso. Ad esempio, se un pod del carico di lavoro viene riavviato, gli audit log per il carico di lavoro, se non sono resi persistenti, possono andare persi.
Prima di iniziare
Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster. a:- .
- Installa gli strumenti necessari
- Scarica
asmcli
- Concedi le autorizzazioni di amministratore del cluster
- Convalida il progetto e il cluster
Prepara la configurazione del gateway
Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway come parte mesh di servizi. Un gateway descrive un bilanciatore del carico che opera a livello perimetrale mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono Envoy che forniscono un controllo granulare sul traffico in entrata e escono dalla rete.
asmcli
non installa istio-ingressgateway
. Ti consigliamo di
il deployment e la gestione
del piano di controllo e dei gateway separatamente. Per ulteriori informazioni
consulta Installazione e upgrade dei gateway.
Personalizzazione dell'installazione di Anthos Service Mesh
Per utilizzare un criterio di controllo, personalizza l'installazione di Cloud Service Mesh:
Installazioni
Segui i passaggi in Installa Cloud Service Mesh. Quando esegui
asmcli install
, includi la seguente opzione:--option audit-authorizationpolicy
Ad esempio:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Assicurati di specificare tutti gli altri file di overlay di cui hai bisogno configurare Cloud Service Mesh.
Completa l'installazione di Cloud Service Mesh per abilitare il sidecar automatico l'iniezione di proxy sui carichi di lavoro. Consulta: Esegui il deployment e riesegui il deployment dei carichi di lavoro.
Upgrade
Segui i passaggi in Esegui l'upgrade di Cloud Service Mesh. Quando esegui
asmcli install
, includi la seguente opzione:--option audit-authorizationpolicy
Ad esempio:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Assicurati di specificare tutti gli altri file di overlay di cui hai bisogno configurare Cloud Service Mesh.
Completa l'installazione di Cloud Service Mesh per abilitare il sidecar automatico l'iniezione di proxy sui carichi di lavoro. Per maggiori dettagli, vedi Passa al nuovo piano di controllo
Utilizzo dell'audit logging
Questa sezione utilizza l'esempio di Bookinfo per dimostrare come utilizzare l'audit logging.
Esegui il deployment dell'applicazione di esempio Bookinfo predefinito.
Ottieni l'indirizzo IP esterno del gateway in entrata e invia richieste all'applicazione di esempio per generare del traffico.
Nella console Google Cloud, vai al menu di navigazione.
e seleziona Logging > Esplora log:Seleziona un progetto Google Cloud.
Poiché non hai ancora eseguito il deployment di un criterio di controllo, non ci sarà alcun controllo logaritmi. Tieni presente che l'audit log è diverso dal log degli accessi. A visualizza i log di accesso di
stackdriver
, inserisci la seguente query nel campo Query campo Builder e fai clic su Esegui query:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Per ulteriori informazioni sull'utilizzo di Esplora log, consulta Panoramica di Esplora log.
Configurazione del criterio di controllo e controllo degli audit log
Questa sezione fornisce diverse opzioni per la verifica dell'applicazione Bookinfo. Dopo aver eseguito il deployment del criterio di controllo, puoi inviare alcune richieste e quindi controllare in Esplora log.
Inserisci il seguente comando per ottenere credenziali di autenticazione di interagire con il cluster. Questo comando imposta anche il contesto corrente
kubectl
al cluster.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Applica il seguente criterio di controllo per controllare le richieste
GET
alla Percorso/productpage
:kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-productpage" namespace: default spec: action: AUDIT rules: - to: - operation: methods: ["GET"] paths: ["/productpage"] EOF
Invia alcune richieste a Bookinfo.
In Esplora log, inserisci la seguente query nel campo Query Builder: e fai clic su Esegui query:
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
La query restituisce log simili ai seguenti:
Applica il seguente criterio per le richieste di controllo a
bookinfo-ratings
completamente gestito di Google Cloud. I criteri di audit sono cumulabili. Dopo aver applicato quanto segue vedi i log di controllo per le richieste a ProductPage e Ratings.kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-ratings" namespace: default spec: action: AUDIT rules: - from: - source: principals: ["cluster.local/ns/default/sa/bookinfo-ratings"] to: - operation: methods: ["GET"] EOF
Il nuovo criterio di controllo deve essere propagato prima di essere applicato.
Invia 10 o più richieste a Bookinfo per assicurarti di raggiungere le valutazioni e quindi controllare l'audit log in Esplora log. L'audit log simile al seguente:
Applica il seguente criterio per eseguire il controllo a tutti i servizi nell'impostazione predefinita nello spazio dei nomi.
kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
Invia altre richieste a Bookinfo, quindi controlla il log di controllo Esplora log. Il log di controllo ora registra tutte le richieste:
Se vuoi limitare il criterio di controllo a ProductPage e Valutazioni, puoi eliminare il criterio
audit-all
:kubectl delete authorizationpolicy audit-all -n default
Risoluzione dei problemi
Se dopo aver abilitato un criterio di controllo non vedi audit log, ecco alcune aspetti che puoi controllare:
Assicurati che ci sia traffico per il periodo di tempo specificato in Esplora log. Se stai testando con Bookinfo, puoi inviare le richieste eseguendo il comando seguente comando più volte:
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
Controlla se è presente un
AuthorizationPolicy
sul gateway in entrata che blocca le richieste al servizio controllato.Controlla i log di accesso a
stackdriver
con il seguente filtro nei log Explorer per verificare se le richieste hanno raggiunto l'applicazione:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Per assicurarti che Stackdriver sia configurato e che l'audit log sia abilitato, esegui il dump della configurazione dello stato attuale di
istiod
. Nella ricercaconfig_dump
, cercaenable_audit_log
e i criteri di controllo .istioctl dashboard envoy POD_NAME.NAMESPACE
Per assicurarti che le tue richieste corrispondano alle regole dei criteri di controllo, puoi: Controllare i log di debug del controllo degli accessi basato su ruoli (RBAC, Role-Based Access Control). Attiva il logging di debug RBAC con il seguente comando:
kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
Invia alcune richieste, quindi controlla i log del pod con Comando
kubectl logs
:kubectl logs POD_NAME -n NAMESPACE -c istio-proxy