Anthos Service Mesh 1.14 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (più recente)
1,19
1,18
1,17
1,16
1,15
1,14
1.13
1.12
1.12

Configurazione delle funzionalità avanzate dei criteri di autorizzazione

Il criterio di autorizzazione di Anthos Service Mesh fornisce controllo dell'accesso a livello di mesh, spazio dei nomi e carico 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 Anthos Service Mesh, tra cui la modalità di prova e il logging dei rifiuti. Le funzionalità descritte in questa pagina presuppongono che tu conosca i concetti fondamentali dei criteri di autorizzazione descritti in Panoramica dei criteri di autorizzazione.

Modalità di prova

Il criterio di autorizzazione di Anthos Service Mesh supporta la modalità di prova, che ti consente di testare un criterio di autorizzazione con traffico di produzione reale senza applicarlo. La modalità di prova consente di comprendere meglio l'effetto di un criterio di autorizzazione prima di applicarlo. Ciò consente di ridurre il rischio di interrompere il traffico di produzione a causa di un criterio di autorizzazione errato.

Puoi utilizzare l'annotazione "istio.io/dry-run": "true" nel criterio di autorizzazione per passare alla modalità di prova.

Esempio di modalità di prova

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 percorso headers 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, Anthos Service Mesh registra il risultato dell'applicazione in Cloud Logging, ma non applica il criterio. La richiesta è sempre consentita ed è possibile controllare Esplora log per decidere se il criterio di autorizzazione funziona come previsto.

Dettagli di logging di prova

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

Vai a Esplora log. Nel seguente URL, sostituisci PROJECT_ID con l'ID progetto:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Nel campo Query-builder, inserisci una query per trovare il criterio di autorizzazione per la modalità di prova. Nella query seguente, sostituisci NAMESPACE 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.
Regola l'intervallo di tempo in base alle tue esigenze.

Il seguente screenshot 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 di prova di Istio. Anthos Service Mesh archivia i risultati di prova in Cloud Logging nelle seguenti etichette:

dry_run_result: il risultato della prova di 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 prova.
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 corrispondenza	Risultato della prova	Cloud Logging
Solo `DENY` criterio	Senza corrispondenza	consentito	dry_run_result: "AuthzAllowed"
Solo `DENY` criterio	Con corrispondenza	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Solo `ALLOW` criterio	Senza corrispondenza	rifiutato	dry_run_result: "Autorizzazione negata"
Solo `ALLOW` criterio	Con corrispondenza	consentito	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Sia il criterio `ALLOW` che `DENY`	Nessuna corrispondenza	rifiutato	dry_run_result: "Autorizzazione negata"
	Corrispondente solo alla norma `DENY`	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Corrispondente solo alla norma `ALLOW`	consentito	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Corrispondente a entrambe le norme	rifiutato	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

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

Rimuovere completamente l'annotazione di prova; oppure
Modifica il valore dell'annotazione di prova in false.

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

Registrazione dei rifiuti

Il criterio di autorizzazione nega una richiesta se non è consentito 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 che sono utili per capire il motivo del rifiuto del traffico. Ad esempio, il log indica il numero di richieste rifiutate dal criterio di autorizzazione, il che può aiutarti a determinare quale regola del criterio ha causato il rifiuto rispetto alle richieste di rifiuto dell'applicazione di backend.

Nell'esempio seguente, l'annotazione dry-run è impostata su "false. Quando applichi il criterio di autorizzazione DENY, viene applicato da Anthos Service Mesh.

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 autorizzazione DENY, puoi visualizzarne i risultati in Esplora log.

Vai a Esplora log. Nel seguente URL, sostituisci PROJECT_ID con l'ID 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 query seguente, sostituisci NAMESPACE 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.
Regola l'intervallo di tempo in base alle tue esigenze.

Lo screenshot seguente mostra una voce di log in Esplora log dopo l'applicazione del criterio deny-path-headers di esempio per applicarlo. Per capire che il criterio di autorizzazione era responsabile dell'errore 403, controlla le etichette:

immagine

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

response_details: è impostato su "AuthzDenied" se il rifiuto è causato da un criterio di autorizzazione.
policy_name: contiene lo spazio dei nomi e il nome del criterio di autorizzazione DENY 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.

Che cosa succede dopo?

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

kubectl get authorizationpolicy --all-namespaces

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

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

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