Configurazione dei criteri di audit per i tuoi servizi

Le API di Google Cloud e il servizio Mesh non supportano solo le API Cloud e il servizio Mesh, sono supportate solo da Cloud

Per maggiori informazioni, consulta la panoramica di Cloud Service Mesh.

Anteprima - Audit policy

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questo tutorial supporta solo l'implementazione del piano di controllo nel cluster.

Un criterio di controllo consente di controllare l'accesso ai dati ai servizi in Cloud Service Mesh. La verifica dei tuoi servizi ti aiuta a rispondere a domande "chi ha fatto cosa, quando e forse perché". Con un criterio di audit, puoi specificare quando creare un audit log e i contenuti dei log. Questa guida spiega come installare Cloud Service Mesh in modo da utilizzare un criterio di controllo.

Poiché gli audit log vengono visualizzati in Esplora log di Cloud Logging nella console Google Cloud, i criteri di audit sono supportati solo sulle seguenti piattaforme:

• GKE su Google Cloud
• GKE su VMware
• Google Distributed Cloud Virtual per Bare Metal

Un criterio di controllo estende AuthorizationPolicy aggiungendo un'azione AUDIT. Ha effetto solo nell'ambito del criterio di destinazione (che può essere un carico di lavoro, uno spazio dei nomi o l'intero mesh). I criteri sono ORed insieme, ovvero viene registrata una richiesta se esiste uno dei criteri previsti. Se a un determinato carico di lavoro non viene applicato alcun criterio di controllo, non viene generato alcun audit log per quel carico di lavoro.

Ecco un esempio di criterio di controllo per controllare tutti gli accessi in scrittura al 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 esiste un 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à dei normali log di accesso. Ad esempio, se un pod di un carico di lavoro viene riavviato, alcuni audit log del carico di lavoro, se non resi persistenti, potrebbero andare persi.

Prima di iniziare

Segui i passaggi descritti in Installare strumenti dipendenti e convalidare il cluster per:

• Installare gli strumenti richiesti
• 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 del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro del mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono un controllo granulare sul traffico in entrata e in uscita dal mesh.

asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire 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 Cloud Service Mesh

Per utilizzare un criterio di controllo, personalizza l'installazione di Cloud Service Mesh:

Installazioni

1. Segui la procedura descritta in Installare 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 per configurare Cloud Service Mesh.

2. Completa l'installazione di Cloud Service Mesh per abilitare l'inserimento automatico proxy sidecar sui tuoi carichi di lavoro. Vedi Eseguire il deployment e rieseguire il deployment dei carichi di lavoro.

Upgrade

1. Segui la procedura descritta 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 per configurare Cloud Service Mesh.

2. Completa l'installazione di Cloud Service Mesh per abilitare l'inserimento automatico proxy sidecar sui tuoi carichi di lavoro. Per maggiori dettagli, consulta Passare al nuovo piano di controllo

Utilizzo dell'audit logging

Questa sezione utilizza l'esempio di Bookinfo per dimostrare come utilizzare l'audit logging.

1. Esegui il deployment dell'applicazione di esempio Bookinfo nello spazio dei nomi predefinito.

2. Ottenere l'indirizzo IP esterno del gateway in entrata e inviare richieste all'applicazione di esempio per generare traffico.

3. Nella console Google Cloud, vai al menu di navigazione e seleziona Logging > Esplora log:
   

   Vai a Esplora log

4. Seleziona un progetto Google Cloud.

5. Poiché non hai ancora eseguito il deployment di un criterio di controllo, non saranno visualizzati audit log. Tieni presente che il log di controllo è diverso dal log degli accessi. Per visualizzare i log di accesso di stackdriver, inserisci la seguente query nel campo Strumento di creazione query e fai clic su Esegui query:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

   Per ulteriori informazioni sull'utilizzo di Esplora log, consulta la panoramica di Esplora log.

Configurazione del criterio di controllo e controllo degli audit log

Questa sezione fornisce varie opzioni per controllare l'applicazione Bookinfo. Dopo aver eseguito il deployment del criterio di controllo, puoi inviare alcune richieste e controllare il log di controllo in Esplora log.

1. Inserisci il seguente comando per ottenere le credenziali di autenticazione per interagire con il cluster. Questo comando imposta anche il contesto attuale per kubectl nel cluster.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION
   

   Nota: per un cluster a livello di regione, sostituisci --region con --zone.

2. Applica il criterio di controllo seguente per controllare le richieste GET per il 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
   

3. Invia alcune richieste a Bookinfo.

4. 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:

   

5. Applica il criterio seguente per controllare le richieste al servizio bookinfo-ratings. I criteri di controllo sono cumulativi. Dopo aver applicato il criterio seguente, visualizzerai gli audit log per le richieste sia a ProductPage che a 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 propagarsi prima di essere applicato.

6. Invia 10 o più richieste a Bookinfo per assicurarti di utilizzare il servizio di valutazione, quindi controlla l'audit log in Esplora log. L'audit log è simile al seguente:

   

7. Applica il criterio seguente per eseguire controlli per tutti i servizi nello spazio dei nomi predefinito.

   kubectl apply -f - << EOF
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     namespace: default
     name: "audit-all"
   spec:
     action: AUDIT
     rules:
       - {}
   EOF
   

8. Invia altre richieste a Bookinfo, quindi controlla l'audit log in Esplora log. Ora il log di controllo registra tutte le richieste:

   

9. Se vuoi limitare il criterio di controllo alla pagina Prodotto e alle valutazioni, puoi eliminare il criterio audit-all:

   kubectl delete authorizationpolicy audit-all -n default
   

Risoluzione dei problemi

Se non vedi log di controllo dopo aver abilitato un criterio di controllo, ecco alcune cose che puoi controllare:

1. Assicurati che sia presente traffico per il periodo di tempo specificato in Esplora log. Se stai testando con Bookinfo, puoi inviare richieste eseguendo più volte il seguente comando:

   curl -s http://EXTERNAL_IP/productpage | grep Bookstore
   

2. Verifica se è presente un valore AuthorizationPolicy sul gateway in entrata che blocca le richieste al servizio controllato.

3. Controlla i log degli accessi stackdriver con il seguente filtro in Esplora log per verificare se le tue richieste hanno raggiunto l'applicazione:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

   

4. Per assicurarti che Stackdriver sia configurato e che l'audit log sia abilitato, esegui il dump della configurazione attuale dello stato istiod. In config_dump cerca enable_audit_log e il nome del criterio di controllo.

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. Per assicurarti che le tue richieste siano corrispondenti alle regole dei criteri di controllo, puoi controllare i log di debug del controllo dell'accesso basato sui ruoli (RBAC). 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'
   

6. Invia alcune richieste, quindi controlla i log del pod con il comando kubectl logs:

   kubectl logs POD_NAME -n NAMESPACE -c istio-proxy
   

Passaggi successivi

• Scopri di più sulla sicurezza in Cloud Service Mesh