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 Anthos Service Mesh. L'audit dei tuoi servizi ti aiuta a rispondere alle domande su "chi ha fatto cosa, quando e probabilmente perché". Con un criterio di audit, puoi specificare quando viene creato un audit log e i relativi contenuti. Questa guida spiega come installare Anthos Service Mesh per usare un criterio di controllo.

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

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

Un criterio di audit estende AuthorizationPolicy aggiungendo un'azione AUDIT. Diventa effettivo solo nell'ambito dei criteri 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 un criterio lo consente. Se non viene applicato alcun criterio di controllo a un determinato carico di lavoro, per quel carico di lavoro non viene generato alcun audit log.

Ecco un esempio di criterio di audit 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 è presente alcun audit log sul gateway in entrata.
  • I contenuti del controllo non sono configurabili.
  • Attualmente, gli audit log di Anthos Service Mesh hanno le stesse proprietà di affidabilità dei normali log di accesso. Ad esempio, se il pod di un carico di lavoro viene riavviato, alcuni audit log per il carico di lavoro, se non sono persistenti, possono andare persi.

Prima di iniziare

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

Prepara la configurazione del gateway

Anthos 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 della rete mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che forniscono un controllo granulare sul traffico che entra e esce dal mesh.

asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment del piano di controllo e dei gateway e di gestirlo separatamente. Per maggiori informazioni, consulta Installazione e upgrade dei gateway.

Personalizzazione dell'installazione di Anthos Service Mesh

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

Installazioni

  1. Segui i passaggi descritti in Installare Anthos 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

    Accertati di specificare eventuali altri file di overlay di cui hai bisogno per configurare Anthos Service Mesh.

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

Upgrade

  1. Segui i passaggi descritti in Eseguire l'upgrade di Anthos 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

    Accertati di specificare eventuali altri file di overlay di cui hai bisogno per configurare Anthos Service Mesh.

  2. Completa l'installazione di Anthos Service Mesh per abilitare l'inserimento automatico di 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. Ottieni l'indirizzo IP esterno del gateway in entrata e invia 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 audit, non ci saranno audit log. Tieni presente che l'audit log è diverso dal log degli accessi. Per visualizzare i log di accesso di stackdriver, inserisci la seguente query nel campo Query 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 audit, puoi inviare alcune richieste e quindi 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 per kubectl sul cluster.

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

  2. Applica il seguente criterio di controllo 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 Query Builder e fai clic su Esegui query:

    logName="projects/PROJECT_ID/logs/server-istio-audit-log"

    La query restituisce log simili ai seguenti:

    immagine

  5. Applica il seguente criterio per controllare le richieste al servizio bookinfo-ratings. I criteri di audit sono cumulabili. Dopo aver applicato il seguente criterio, vedrai 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 essere propagato prima di essere applicato.

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

    immagine

  7. Applica il seguente criterio per eseguire il controllo 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. Il log di controllo ora registra tutte le richieste:

    immagine

  9. Se vuoi limitare di nuovo 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 non vedi audit log dopo aver abilitato un criterio di controllo, ecco alcune cose che puoi controllare:

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

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

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

  3. Controlla i log di accesso di 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"

    immagine

  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 controllo.

    istioctl dashboard envoy POD_NAME.NAMESPACE

    immagine immagine immagine

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