Configurazione dei criteri di audit per i tuoi servizi

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio e non supporta le API. Google Cloud Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Anteprima : criteri di audit

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Questo tutorial supporta solo l'implementazione del control plane in-cluster .

Un criterio di audit ti consente di controllare l'accesso ai dati dei tuoi servizi in Cloud Service Mesh. L'audit dei servizi ti aiuta a rispondere alle domande "chi ha fatto cosa, quando e, possibilmente, perché". Con un criterio di audit, puoi specificare quando viene creato un audit log e il contenuto dei log. Questa guida spiega come installare Cloud Service Mesh in modo da poter utilizzare un criterio di audit.

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

• GKE su Google Cloud
• Google Distributed Cloud (solo software) per VMware
• Google Distributed Cloud (solo software) per bare metal

Un criterio di audit estende AuthorizationPolicy aggiungendo un'azione AUDIT. Ha effetto solo nell'ambito del criterio di destinazione (che può essere un workload, uno spazio dei nomi o l'intero mesh). I criteri vengono ORed insieme, ovvero una richiesta viene registrata se un criterio lo prevede. Se nessun criterio di audit si applica a un determinato workload, non viene generato alcun audit log per quel workload.

Di seguito è riportato un esempio di criterio di audit per controllare tutti gli accessi WRITE 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 su ingress-gateway.
• Il contenuto dell'audit non è configurabile.
• Attualmente, gli audit log di Cloud Service Mesh hanno la stessa proprietà di affidabilità dei normali access log. Ad esempio, se un pod di workload viene riavviato, alcuni audit log per il workload, se non persistenti, possono essere persi.

Prima di iniziare

Segui i passaggi descritti in Installa strumenti dipendenti e convalida il cluster per:

• Installare gli strumenti richiesti
• Scaricare asmcli
• Concedere le autorizzazioni amministrative del cluster
• Convalidare il progetto e il cluster

Prepara la configurazione del gateway

Cloud Service Mesh ti offre la possibilità di eseguire il deployment dei gateway e di gestirli all'interno del mesh di servizi. Un gateway descrive un bilanciatore del carico che opera al limite del mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che offrono un controllo granulare sul traffico in entrata e in uscita dal mesh.

asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e gestire separatamente il control plane e i gateway. Per ulteriori informazioni, consulta Installazione e upgrade dei gateway.

Personalizzazione dell'installazione di Cloud Service Mesh

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

Installazioni

1. Segui i passaggi descritti 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 necessari per configurare Cloud Service Mesh.

2. Completa l'installazione di Cloud Service Mesh per abilitare l'inserimento automatico del proxy sidecar sui workload. Vedi Eseguire il deployment e il nuovo deployment dei workload.

Upgrade

1. Segui i passaggi descritti in Eseguire 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 necessari per configurare Cloud Service Mesh.

2. Completa l'installazione di Cloud Service Mesh per abilitare l'inserimento automatico del proxy sidecar sui workload. Per maggiori dettagli, vedi Passare al nuovo control plane.

Utilizzo dell'audit logging

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

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

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

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

   Vai a Esplora log

4. Seleziona un Google Cloud progetto.

5. Poiché non hai ancora eseguito il deployment di un criterio di audit, non saranno presenti audit log. Tieni presente che l'audit log è diverso dall'access log. Per visualizzare stackdriver access log, inserisci la seguente query nel campo Generatore di query e fai clic su Esegui query:

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

   Per ulteriori informazioni sull'utilizzo di Esplora log, vedi Panoramica di Esplora log.

Configurazione del criterio di audit e controllo degli audit log

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

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

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

   Nota: per il cluster regionale, sostituisci --region con --zone.

2. Applica il seguente criterio di audit per controllare le richieste GET al 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 Generatore di query, 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 seguente criterio per controllare le richieste al servizio bookinfo-ratings. I criteri di audit sono cumulativi. Dopo aver applicato il seguente criterio, vedrai gli audit log 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 audit deve essere propagato prima di entrare in vigore.

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

   

7. Applica il seguente criterio di audit a 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. L'audit log ora registra tutte le richieste:

   

9. Se vuoi limitare di nuovo il criterio di audit a ProductPage e Ratings, puoi eliminare il criterio audit-all:

   kubectl delete authorizationpolicy audit-all -n default
   

Risoluzione dei problemi

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

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

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

2. Controlla se esiste un AuthorizationPolicy sul gateway in entrata che blocca le richieste al servizio sottoposto ad audit.

3. Controlla gli access log stackdriver con il seguente filtro in Esplora log per verificare se le 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 dello stato attuale di istiod. In config_dump, cerca enable_audit_log e il nome del criterio di audit.

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. Per assicurarti che le richieste corrispondano alle regole dei criteri di audit, puoi controllare i log di debug del controllo dell'accesso basato sui ruoli (RBAC). Attiva il logging di debug RBAC con il comando seguente:

   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