Configurazione dei criteri di audit per i tuoi servizi

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

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

Poiché visualizzi i log di controllo in Esplora log di Cloud Logging nella console Google Cloud, i criteri di controllo 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 controllo estende AuthorizationPolicy aggiungendo un'azione AUDIT. Viene applicato 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 una richiesta viene registrata se lo prevede un criterio. Se a un determinato workload non viene applicato alcun criterio di controllo, non viene generato alcun log di controllo per quel workload.

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 è presente alcun log di controllo su ingress-gateway.
  • 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 viene riavviato un pod del carico di lavoro, alcuni log di controllo per il carico di lavoro, se non sono permanenti, 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

Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway all'interno del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera all'esterno della rete mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti 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 il piano di controllo e i gateway separatamente. Per ulteriori informazioni, consulta Installare e eseguire l'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 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 eventuali altri file overlay necessari per configurare Cloud Service Mesh.

  2. Completa l'installazione di Cloud Service Mesh per abilitare l'iniezione automatica di proxy sidecar nei tuoi carichi di lavoro. Consulta Esegui il deployment e il nuovo deployment dei carichi di lavoro.

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 eventuali altri file overlay necessari per configurare Cloud Service Mesh.

  2. Completa l'installazione di Cloud Service Mesh per abilitare l'iniezione automatica di proxy sidecar nei tuoi carichi di lavoro. Per maggiori dettagli, consulta Passare al nuovo control plane

Utilizzo dell'audit logging

Questa sezione utilizza l'esempio Bookinfo per dimostrare come utilizzare la registrazione degli audit.

  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 del traffico.

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

    Vai a Esplora log

  4. Seleziona un progetto Google Cloud.

  5. Poiché non hai ancora implementato un criterio di controllo, non ci saranno audit log. Tieni presente che l'audit log è diverso dal log di accesso. Per visualizzare i log di accesso 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 verifica dei log di controllo

Questa sezione fornisce diverse opzioni per il controllo dell'applicazione Bookinfo. Dopo aver implementato il criterio di controllo, puoi inviare alcune richieste e poi controllare il log di controllo in Esplora log.

  1. Inserisci il comando seguente per recuperare le credenziali di autenticazione per interagire con il cluster. Questo comando imposta anche il contesto corrente 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 alle richieste di controllo al servizio bookinfo-ratings. I criteri di audit sono cumulativi. Dopo aver applicato le seguenti norme, vedrai 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

    Prima che il nuovo criterio di controllo abbia effetto, deve essere propagato.

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

    immagine

  7. Applica il seguente criterio di 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 il log di controllo in Esplora log. Ora l'audit log registra tutte le richieste:

    immagine

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

    kubectl delete authorizationpolicy audit-all -n default

Risoluzione dei problemi

Se non visualizzi alcun log di controllo dopo aver attivato 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 esegui il test con Bookinfo, puoi inviare richieste eseguendo più volte il seguente comando:

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

  2. Controlla se nel gateway di ingresso è presente un AuthorizationPolicy che blocca le richieste al servizio sottoposto a controllo.

  3. Controlla i log di accesso stackdriver con il seguente filtro in Logs Explorer per verificare se le 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 istiod corrente. 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 tue richieste corrispondano alle regole dei criteri di controllo, puoi controllare i log di debug del controllo dell'accesso basato sui ruoli (RBAC). Attiva la registrazione 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