Configurazione dei criteri di audit per i tuoi servizi

Un criterio di controllo consente di controllare l'accesso ai dati ai servizi in Anthos Service Mesh. Controllare i servizi ti aiuta a rispondere a domande come "chi ha fatto cosa, quando e possibilmente perché". Con un criterio di controllo, puoi specificare quando viene creato un audit log e il contenuto dei log. Puoi visualizzare gli audit log in Esplora log di Cloud Logging nella console Google Cloud. Questa guida spiega come installare Anthos Service Mesh su GKE su Google Cloud in modo da poter utilizzare un criterio di controllo.

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 insieme ORed, il che significa che viene registrata una richiesta se esiste uno di questi criteri. Se a un determinato carico di lavoro non viene applicato alcun criterio di controllo, non viene generato alcun audit log.

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 alcun log di controllo sul gateway in entrata.
I contenuti del controllo non sono configurabili.
Attualmente, gli audit log di Anthos Service Mesh hanno la stessa proprietà di affidabilità dei normali log degli accessi. Ad esempio, se un pod di un carico di lavoro viene riavviato, alcuni audit log del carico di lavoro potrebbero andare persi.

Personalizzazione dell'installazione di Anthos Service Mesh

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

Segui i passaggi in Installazione di Anthos Service Mesh su GKE per utilizzare uno script fornito da Google per installare Anthos Service Mesh. Quando esegui lo script, includi la seguente opzione:

--option audit-authorizationpolicy

Ad esempio:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH  \
  --enable_all \
  --option audit-authorizationpolicy

Completa l'installazione di Anthos Service Mesh per abilitare l'inserimento automatico di proxy sidecar sui tuoi carichi di lavoro. Per maggiori dettagli, consulta Deployment e nuova esecuzione del deployment dei carichi di lavoro.

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 nello spazio dei nomi predefinito.
Recuperare l'indirizzo IP esterno del gateway in entrata e inviare richieste all'applicazione di esempio per generare traffico.
Nella console Google Cloud, vai al menu di navigazione e seleziona Logging > Esplora log:

Vai a Esplora log
Seleziona un progetto Google Cloud.
Poiché non hai ancora eseguito il deployment di un criterio di controllo, non ci saranno audit log. Tieni presente che il log di controllo è diverso dal log degli accessi. Per visualizzare i log degli accessi a stackdriver, inserisci la seguente query nel campo Strumento per la creazione di 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 diverse opzioni per il controllo dell'applicazione Bookinfo. Dopo aver eseguito il deployment del criterio di controllo, puoi inviare alcune richieste e quindi controllare l'audit log in Esplora log.

Inserisci il comando seguente 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.

Applica il seguente criterio di controllo per controllare le richieste GET nel 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 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:
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 per ProductPage che per 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 diventare effettivo.
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:

Applica il criterio seguente 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

Invia altre richieste a Bookinfo, quindi controlla l'audit log in Esplora log. Ora il log di controllo registra tutte le richieste:
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 visualizzi alcun log di controllo dopo aver abilitato un criterio di controllo, puoi controllare quanto segue:

Assicurati che sia presente 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
```
Verifica se è presente un AuthorizationPolicy sul gateway in entrata che blocca le richieste al servizio controllato.
Controlla i log degli accessi a 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"
```
Per assicurarti che Stackdriver sia configurato e che l'audit log sia abilitato, esegui il dump della configurazione dello stato istiod attuale. Nella sezione config_dump, cerca enable_audit_log e il nome del criterio di controllo.
```
istioctl dashboard envoy POD_NAME.NAMESPACE
```
Per assicurarti che le tue richieste siano corrispondenti alle regole dei criteri di controllo, puoi controllare i log di debug del controllo dell'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'
```
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 Anthos Service Mesh