Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione delle funzionalità avanzate dei criteri di autorizzazione

Il criterio di autorizzazione di Cloud Service Mesh fornisce controllo dell'accesso a livello di mesh, spazio dei nomi e caricamento di lavoro per i tuoi carichi di lavoro nel mesh. Questa pagina descrive i dettagli sulla configurazione delle funzionalità avanzate dei criteri di autorizzazione di Cloud Service Mesh, tra cui la modalità di prova e la registrazione dei rifiuti. Le funzionalità descritte in questa pagina presuppongono che tu abbia familiarità con i concetti fondamentali delle norme di autorizzazione descritti nella Panoramica delle norme di autorizzazione.

Modalità dry run

Il criterio di autorizzazione di Cloud Service Mesh supporta la modalità di prova, che consente di testare un criterio di autorizzazione con traffico di produzione reale senza applicarlo. La modalità di prova ti consente di comprendere meglio l'effetto di un criterio di autorizzazione prima di applicarlo. In questo modo si riduce il rischio di interrompere il traffico di produzione causato da un criterio di autorizzazione errato.

Utilizza l'annotazione "istio.io/dry-run": "true" nel criterio di autorizzazione per impostarlo sulla modalità di prova.

Esempio di modalità dry run

L'esempio seguente, deny-path-headers, mostra un criterio con l'annotazione dry-run impostata su "true. Il criterio di autorizzazione nega le richieste al percorsoheaders e consente tutte le altre richieste.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Quando applichi un criterio di autorizzazione in modalità di prova, Cloud Service Mesh registra il risultato dell'applicazione in Cloud Logging, ma non applica il criterio. La richiesta è sempre consentita e puoi controllare Explorer dei log per decidere se il criterio di autorizzazione funziona come previsto.

Dettagli di logging del dry run

Dopo aver applicato un criterio di autorizzazione in modalità di prova, puoi visualizzarne i risultati in Esplora log.

Vai a Esplora log. Nell'URL seguente, sostituisci PROJECT_ID con l'ID del tuo progetto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Nel campo Query Builder, inserisci una query per trovare il criterio di autorizzazione della modalità di prova. Nella seguente query, sostituisciNAMESPACE con il tuo spazio dei nomi:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Fai clic su Esegui query.
Modifica l'intervallo di tempo in base alle tue esigenze.

Lo screenshot seguente mostra le etichette di prova nel log del traffico in Esplora log dopo l'applicazione del criterio deny-path-headers di esempio:

immagine

La modalità di prova supporta i criteri di autorizzazione ALLOW e DENY, oltre ai risultati della modalità di prova di Istio. Cloud Service Mesh archivia i risultati della simulazione in Cloud Logging nei seguenti etichette:

dry_run_result: il risultato della prova è "AuthzAllowed" o "AuthzDenied".
dry_run_policy_name: lo spazio dei nomi e il nome del criterio di autorizzazione corrispondente che prende la decisione di dry run.
dry_run_policy_rule: l'indice della regola del criterio di autorizzazione corrispondente che prende la decisione di prova.

La tabella seguente mostra i dettagli registrati per un criterio di autorizzazione in modalità di prova:

Criterio di autorizzazione applicato in modalità di prova	Risultato della corrispondenza	Risultato del test di prova	Cloud Logging
Solo criterio `DENY`	Senza corrispondenza	consentito	dry_run_result: "AuthzAllowed"
Solo criterio `DENY`	Con corrispondenza	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Solo criterio `ALLOW`	Senza corrispondenza	rifiutato	dry_run_result: "AuthzDenied"
Solo criterio `ALLOW`	Con corrispondenza	consentito	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Sia le norme di `ALLOW` che quelle di `DENY`	Nessuna corrispondenza	rifiutato	dry_run_result: "AuthzDenied"
	Solo norma `DENY` corrispondente	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Solo norma `ALLOW` corrispondente	consentito	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Corrispondenza con entrambe le norme	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

Quando hai la certezza del risultato della prova, puoi disattivare la modalità di prova utilizzando uno dei seguenti approcci:

Rimuovere completamente l'annotazione del trasferimento di prova.
Modifica il valore dell'annotazione di prova in false.

Dopo aver applicato il criterio con la modalità di prova disattivata, Cloud Service Mesh lo applica.

Log di rifiuto

Il criterio di autorizzazione nega una richiesta se non è consentita dal criterio. Per i protocolli HTTP (incluso gRPC), la richiesta viene rifiutata con il codice di stato 403. Per i protocolli non HTTP, la connessione viene terminata direttamente. Il log del traffico di Cloud Logging include informazioni aggiuntive utili per comprendere il motivo del rifiuto del traffico. Ad esempio, il log indica quante richieste vengono rifiutate dal criterio di autorizzazione, il che può aiutarti a determinare quale regola del criterio ha causato il rifiuto rispetto ai rifiuti dell'applicazione di backend.

Nel seguente esempio, l'annotazione dry-run è impostata su "false. Quando applichi il criterio di autorizzazione DENY, Cloud Service Mesh lo applica.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Dopo aver applicato un criterio di autorizzazioneDENY, puoi visualizzare i risultati del criterio in Esplora log.

Vai a Esplora log. Nell'URL seguente, sostituisci PROJECT_ID con l'ID del tuo progetto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Nel campo Query Builder, inserisci una query per trovare il criterio di autorizzazione DENY. Nella seguente query, sostituisciNAMESPACE con il tuo spazio dei nomi:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Fai clic su Esegui query.
Modifica l'intervallo di tempo in base alle tue esigenze.

Lo screenshot seguente mostra una voce di log in Esplora log dopo l'applicazione della norma di esempio deny-path-headers per applicarla. Puoi capire che il criterio di autorizzazione è responsabile del codice 403 osservando le etichette:

immagine

Il log del traffico di Logs Explorer include le seguenti etichette per il rifiuto dell'autorizzazione:

response_details: viene impostato su "AuthzDenied" se il rifiuto è causato da un criterio di autorizzazione.
policy_name: contiene lo spazio dei nomi e il nome del criterioDENY di autorizzazione che causa il rifiuto. Il valore è nel formato <Namespace>.<Name>, ad esempio foo.deny-path-headers indica il criterio di autorizzazione deny-path-headers nello spazio dei nomi foo.
policy_rule: contiene l'indice della regola all'interno del criterio di autorizzazione che causa il rifiuto. Ad esempio, 0 indica la prima regola all'interno del criterio.

Passaggi successivi

Per un elenco di tutti i criteri di autorizzazione nel mesh di servizi:

kubectl get authorizationpolicy --all-namespaces

Se è in vigore un criterio di autorizzazione, puoi eliminarlo con kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Per ulteriori informazioni su come ottenere il log del traffico, consulta Accedere ai log in Cloud Logging.