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

Configurazione dell'autenticazione utente di Anthos Service Mesh

L'autenticazione utente Anthos Service Mesh è una soluzione integrata per l'autenticazione dell'utente finale basata su browser e controllo dell'accesso ai carichi di lavoro di cui hai eseguito il deployment. Consente l'integrazione con i provider di identità (IdP) esistenti per l'autenticazione degli utenti e utilizza le API Istio e i criteri di autorizzazione per la gestione degli accessi. È un'alternativa facile da usare all'autenticazione JWT (JSON Web Token) Istio.

Un caso d'uso tipico è quando un'organizzazione utilizza Anthos Service Mesh per ospitare un'applicazione web a cui la forza lavoro può accedere tramite un browser web. Inoltre, l'organizzazione deve utilizzare il proprio provider di identità esistente per gestire le identità degli utenti. L'autenticazione utente di Anthos Service Mesh consente agli utenti di eseguire facilmente l'autenticazione utilizzando un flusso di accesso e consenso OpenID Connect (OIDC) standard basato sul web. Quando l'utente esegue l'autenticazione, Anthos Service Mesh applica i criteri di autorizzazione di Istio e, se l'autorizzazione è andata a buon fine, trasmette l'identità ai carichi di lavoro in un formato di credenziali sicuro.

Come funziona

L'autenticazione utente di Anthos Service Mesh introduce un nuovo componente, authservice. Questo componente si integra con il traffico in entrata basato su Envoy come un servizio di autorizzazione esterno che intercetta tutte le richieste di autenticazione in entrata. authservice implementa il lato client del protocollo OIDC e consente agli utenti di accedere alle applicazioni tramite un browser, in cui gli utenti completano un flusso di autenticazione e consenso interattivo per stabilire una sessione di breve durata. authservice implementa protocolli standard di settore per l'integrazione con qualsiasi provider di identità che può fungere da server di autorizzazione OIDC. Quando l'utente viene autenticato, le informazioni sull'entità vengono incapsulate in un RCToken in formato JWT, firmato da authservice, che inoltra al livello di autorizzazione Istio in entrata. Questo modello fornisce controllo dell'accesso perimetrale per il traffico nel mesh. Se l'utente è autorizzato ad accedere a una risorsa, questo RCToken viene inoltrato anche ai microservizi per ottenere informazioni sull'entità e applicare controllo dell'accesso granulare.

Il seguente diagramma mostra la posizione di authservice nel mesh e la relativa correlazione con le altre parti del mesh, ad esempio l'ingresso, i carichi di lavoro, il browser dell'utente e qualsiasi IdP esistente.

autenticazione degli utenti finali

Gli amministratori possono installare authservice come componente aggiuntivo nell'installazione di Anthos Service Mesh. Una volta installato, authservice legge la configurazione dell'endpoint OIDC e le altre impostazioni associate definite nella risorsa personalizzata UserAuth. L'amministratore può utilizzare le API ExternalAuthorization di Anthos Service Mesh per configurare auth_server come filtro in entrata.

Installare il servizio di autenticazione degli utenti

I passaggi seguenti spiegano come configurare authservice.

Prerequisiti

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

Se utilizzi Anthos Service Mesh gestito su un cluster privato, assicurati che il cluster sia in grado di inviare il traffico in uscita all'IdP.

Importante: kpt è uno strumento open source che ti aiuta a pacchettizzare, personalizzare, convalidare e applicare risorse Kubernetes. Assicurati di avere kpt versione 1.0 o successiva.
Scarica il pacchetto kpt:
```
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 .
cd asm-user-auth/
```
Questo comando recupera un pacchetto kpt con la configurazione authservice consigliata dal repository pubblico. Il pacchetto contiene manifest per eseguire il deployment del container authservice come pod nello spazio dei nomi asm-user-auth. Configura inoltre il gateway in entrata in modo che richieda l'autorizzazione per tutte le richieste.

Configura un provider di autorizzazione esterno ed esegui il deployment di un gateway in entrata

Per installare il servizio di autenticazione degli utenti, puoi personalizzare l'installazione di Anthos Service Mesh aggiungendo un provider di autorizzazione esterno. I passaggi richiesti variano a seconda che utilizzi Anthos Service Mesh gestito o in-cluster.

Gestito

Aggiorna la configurazione mesh in Istio ConfigMap per aggiungere un provider di autorizzazione esterno. Nel comando seguente, utilizza lo stesso REVISION_LABEL utilizzato per il provisioning gestito di Anthos Service Mesh (ad esempio asm-managed, asm-managed-rapid o asm-managed-stable):
```
kubectl edit configmap istio-REVISION_LABEL -n istio-system
```

Aggiungi il provider dell'estensione nel campo mesh:

mesh: |-
...
  extensionProviders:
  - name: "asm-userauth-grpc"
    envoyExtAuthzGrpc:
      service: "authservice.asm-user-auth.svc.cluster.local"
      port: "10003"

Crea ed etichetta lo spazio dei nomi asm-user-auth.

kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION_LABEL --overwrite

Installa un gateway in entrata nello spazio dei nomi asm-user-auth.
```
kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
```
Nota: DIR_PATH si riferisce alla località del repository anthos-service-mesh-packages sulla tua macchina. Se non hai questo repository sulla tua macchina, clonalo: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

Nel cluster

Ottieni l'overlay di autenticazione utente di esempio e aggiornalo in caso di personalizzazioni nella rete mesh. La best practice consigliata prevede di conservare questo file di overlay nel controllo del codice sorgente.
```
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.3/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
```
Segui la procedura per installare Anthos Service Mesh con overlay per utilizzare uno script fornito da Google e installare Anthos Service Mesh con l'overlay di autenticazione utente. Ad esempio:
```
./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --custom_overlay user-auth-overlay.yaml
```
Importante: se personalizzi l'installazione con più overlay, assicurati che l'opzione --custom_overlay includa tutti i file degli overlay.

I pacchetti kpt di autenticazione dell'utente creano un AuthorizationPolicy per fare riferimento al provider di autorizzazione esterno specificato da pkg/ext-authz.yaml.
Crea ed etichetta lo spazio dei nomi asm-user-auth.
```
kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
```
Puoi trovare il valore dell'etichetta REVISION controllando kubectl get pod -n istio-system -L istio.io/rev
Installa il gateway Istio nello spazio dei nomi asm-user-auth.
```
kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
```
Nota: DIR_PATH si riferisce alla località del repository anthos-service-mesh-packages sulla tua macchina. Se non hai questo repository sulla tua macchina, clonalo: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

Prepara la configurazione del client OIDC

Per impostare la configurazione del client OIDC, segui questi passaggi. Questa guida utilizza Google come IdP, ma puoi utilizzare qualsiasi IdP che supporti l'autenticazione OIDC.

Nella console Google Cloud, vai ad API e servizi > Credenziali.

Vai a Credenziali
Vai a Crea credenziali, quindi scegli ID client OAuth. Se necessario, imposta le opzioni della schermata di consenso OAuth, quindi configura le seguenti opzioni:
- Imposta Tipo di applicazione su Applicazione web.
- Imposta URI di reindirizzamento autorizzato su https://REDIRECT_HOST/REDIRECT_PATH. Ad esempio, per localhost, potresti impostare https://localhost:8443/_gcp_asm_authenticate.
Quindi, fai clic su Salva.

Inoltre, salva la configurazione del client OIDC per utilizzarla in un secondo momento.

export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

Imposta l'URL di reindirizzamento e il secret per il gateway in entrata

OAuth2 richiede un URL di reindirizzamento ospitato su un endpoint protetto da HTTPS. Questi comandi sono a scopo di esempio e semplificano la configurazione generando un certificato autofirmato per il gateway in entrata Istio.

Genera un certificato autofirmato:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
 -days 365 -nodes -subj '/CN=localhost'

Crea un secret per il gateway in entrata che ospiti il traffico HTTPS:

kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \
--cert=cert.pem

Applicare le chiavi di crittografia e firma

L'authservice ha bisogno di due set di chiavi per funzionare correttamente. La prima è una chiave simmetrica per crittografia e decriptazione. Questa chiave viene utilizzata per criptare lo stato della sessione prima di impostarlo come cookie.

Il secondo set di chiavi è costituito da una coppia di chiave pubblica/privata. Questa chiave viene utilizzata per firmare le informazioni utente autenticate in formato JWT come RCToken. La chiave pubblica di questa coppia viene pubblicata in un endpoint predefinito che i file collaterali possono utilizzare per convalidare il JWT.

Il pacchetto di autenticazione utente kpt contiene due chiavi di esempio per una configurazione rapida. Tuttavia, per generare queste chiavi puoi utilizzare il tuo sistema di gestione delle chiavi preferito.

Prepara la chiave di crittografia della sessione con il formato seguente o utilizza l'esempio dal pacchetto, che puoi visualizzare entro il giorno cat ./samples/cookie_encryption_key.json.
```
{
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "k":"YOUR_AES_KEY",
        "useAfter": 1612813735
     }
  ]
}
```
Puoi generare una chiave AES di test con il seguente comando:
```
openssl rand -base64 32
```

Prepara la chiave di firma RCToken con il seguente formato o utilizza l'esempio di pkg, che puoi visualizzare entro il giorno cat ./samples/rctoken_signing_key.json.

{
  "keys":[
     {
        "kty":"RSA",
        "kid":"rsa-signing-key",
        "k":"YOUR_AES_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735  # unix timestamp
     }
  ]
}

Puoi generare una chiave privata RSA a 256 bit di test con il seguente comando:

openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256

Crea il secret di Kubernetes, che authservice installerà nel proprio file system.

kubectl create secret generic secret-key  \
    --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
    --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
    --namespace=asm-user-auth

Eseguire il deployment del servizio di autenticazione degli utenti

I comandi seguenti creano il servizio di autenticazione utente e il deployment nello spazio dei nomi asm-user-auth.

Imposta i valori necessari per la configurazione dell'autenticazione utente. L'ID client e il secret sono archiviati come secret di Kubernetes, perciò usiamo Base64 per codificarli. Visita il repository pubblico per visualizzare tutti i setter disponibili.

kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
  client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
  client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
  issuer-uri="${OIDC_ISSUER_URI}" \
  redirect-host="${OIDC_REDIRECT_HOST}" \
  redirect-path="${OIDC_REDIRECT_PATH}"

Applica il pacchetto kpt:

# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg

authservice utilizza il CRD UserAuthConfig per fornire l'autenticazione dell'utente finale. UserAuthConfig è configurabile in tempo di esecuzione e puoi aggiornarlo per modificare il comportamento di authservice e configurarlo con gli endpoint per qualsiasi server di autorizzazione OIDC.

Puoi visualizzare il file in base a cat pkg/user_auth_config.yaml, contiene i seguenti campi:

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}

Per le descrizioni dettagliate dei campi user_auth_config.yaml, consulta i dettagli di configurazione dell'autenticazione utente.

Eseguire attività post-installazione

Una volta completati i passaggi di installazione, sarà necessario eseguire le seguenti operazioni.

Attivare l'autenticazione utente per le applicazioni

Questa sezione mostra come abilitare l'autenticazione utente, utilizzando l'applicazione di esempio httpbin come esempio.

L'autenticazione utente di Anthos Service Mesh utilizza un criterio di autorizzazione digitato CUSTOM per attivare il flusso OIDC.

Dopo aver installato il gateway Istio, configuralo per gestire il traffico HTTPS utilizzando il certificato TLS userauth-tls-cert che hai creato in precedenza. Di seguito è riportata la configurazione pkg/gateway.yaml che hai appena installato.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

Etichetta lo spazio dei nomi default per abilitare l'inserimento automatico di istio-proxy per i deployment.
```
kubectl label namespace default istio.io/rev=REVISION --overwrite
```

Esegui il deployment di httpbin nello spazio dei nomi default.

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default

Aggiorna httpbin per utilizzare questo gateway per la gestione del traffico HTTPS e usa il port forwarding per accedere all'applicazione localmente:

kubectl apply -f./samples/httpbin-route.yaml -n default
kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  gateways:
  - asm-user-auth/userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /ip
    - uri:
        prefix: /headers
    name: httpbin-routes
    route:
    - destination:
        host: httpbin.default.svc.cluster.local
        port:
          number: 8000

Il gateway in entrata sulla porta 8443 verrà inoltrato a localhost per rendere l'applicazione accessibile in locale.

Esegui il deployment di samples/rctoken-authz.yaml per abilitare RequestAuthentication e AuthorizationPolicy per verificare l'RCToken per le richieste.

kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth

Esempio samples/rctoken-authz.yaml:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "authservice.asm-user-auth.svc.cluster.local"
    audiences:
    - "test_audience"
    jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
    fromHeaders:
    - name: X-ASM-RCTOKEN
    forwardOriginalToken: true
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience

Verificare l'autenticazione utente

Il httpbin gestisce due percorsi: /ip è accessibile pubblicamente e /headers richiede all'utente finale di accedere tramite il suo IdP configurato.

Verifica di poter accedere direttamente a /ip visitando https://localhost:8443/ip.
Verifica di visualizzare la pagina di accesso OIDC visitando https://localhost:8443/headers.
Dopo l'accesso, fai clic su Avanti e verifica che il reindirizzamento venga visualizzato alla pagina /headers.

Configura i criteri di autorizzazione

Dopo aver completato la configurazione nei passaggi precedenti, ogni utente verrà reindirizzato tramite un flusso di autenticazione basato sul web. Al completamento del flusso, authservice genererà un RCToken in formato JWT, che utilizza per trasmettere le informazioni utente autenticate.

Aggiungi criteri di autorizzazione Istio in entrata per garantire che venga eseguito un controllo di autorizzazione per ogni utente autenticato:
```
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
```

Il file httpbin-authz.yaml configura il gateway in entrata in modo da convalidare il token RC emesso da authservice e autorizza solo quando il JWT contiene i campi desiderati, ad esempio segmenti di pubblico ed emittenti.

Vedi il seguente esempio di criterio di autorizzazione:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/ip"]
  - to:
    when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience
    - key: request.auth.claims[sub]
      values:
      - allowed_user_sub_1  # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.

Configura le impostazioni specifiche per l'ambiente

I passaggi precedenti utilizzano localhost e un certificato HTTPS autofirmato per la configurazione rapida. Per l'uso reale in produzione, utilizza il tuo dominio, ad esempio example.com.

Inoltre, assicurati che certificateAuthorityData abbia i contenuti del certificato radice previsti. Ad esempio, se l'IdP è attendibile con i certificati radice del sistema, puoi lasciarlo vuoto. Se esiste un proxy HTTPS che termina la connessione HTTPS, questo deve essere impostato sul certificato radice del proxy.

Gestisci e ruota le chiavi

Esistono due serie di chiavi utilizzate da authservice. Puoi ruotare ogni chiave in modo indipendente. Tuttavia, prima di ruotare le chiavi, è importante capire come funziona la rotazione.

Entrambe le chiavi sono in formato JSON. Il campo useAfter specifica il timestamp da quando la chiave sarà considerata in uso. Durante una rotazione della chiave, dovresti includere le chiavi vecchie e nuove nel file JSON. Ad esempio, nell'esempio seguente, new-key verrà utilizzato solo dopo il timestamp 1712813735.

{
   "keys":[
      {
         "kty":"RSA",
         "kid":"old-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1612813735, # unix timestamp
      }
      {
      "kty":"RSA",
         "kid":"new-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1712813735, # unix timestamp
      }
   ]
}

Anthos Service Mesh utilizza la chiave simmetrica per criptare i dati delle sessioni archiviati nei cookie del browser. Per garantire la validità delle sessioni esistenti, authservice tenta la decrittografia con tutte le chiavi del set di chiavi. Al momento della rotazione, authservice utilizzerà la nuova chiave per criptare le nuove sessioni e continuerà a tentare la decrittografia con le chiavi precedenti.

La coppia di chiave pubblica/privata viene utilizzata per firmare RCToken. La chiave pubblica viene trasmessa ai file collaterali da istiod per la verifica JWT. È fondamentale che i file collaterali ricevano la nuova chiave pubblica prima che authservice inizi a utilizzarla per firmare il RCToken. A questo scopo, authservice inizia a pubblicare la chiave pubblica subito dopo l'aggiunta della chiave, ma attende molto tempo prima di iniziare a utilizzarla per firmare RCToken.

In sintesi, quando esegui rotazioni delle chiavi ti consigliamo di:

Esegui rotazioni delle chiavi regolari o on demand in base alle tue esigenze.
Nel formato JSON, includi sia la chiave corrente sia quella nuova. Le nuove chiavi devono essere associate a un timestamp futuro. Ti consigliamo di specificare un timestamp almeno un paio d'ore prima dell'ora attuale.
Monitora e conferma che i servizi siano ancora integri dopo che la nuova chiave è in uso. Attendi almeno un giorno dall'utilizzo della nuova chiave prima di andare al passaggio successivo.
Rimuovi le vecchie chiavi dalle voci JSON. Non sono più necessari.

Distribuzione multi-cluster

L'autenticazione utente di Anthos Service Mesh supporta il deployment di più cluster. Devi eseguire il deployment dell'autenticazione utente in ogni cluster, come descritto sopra. La configurazione dell'autenticazione utente, come la risorsa personalizzata UserAuth, il client secret OIDC e le chiavi di crittografia, deve essere replicata in ogni cluster.

Per impostazione predefinita, il gateway in entrata bilancia il carico delle richieste di autenticazione in una qualsiasi delle istanze authservice. Puoi utilizzare una regola di destinazione per configurare il gateway in entrata in modo che invii richieste a authservice nello stesso cluster e che effettui il failover solo su authservice di altri cluster.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: authservice-fail-over
  namespace: asm-user-auth
spec:
  host: authservice.asm-user-auth.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from:  us-east
          to: us-west
        - from: us-west
          to: us-east

Come per l'altra configurazione, questa deve essere configurata in ogni cluster.

Mappatura delle rivendicazioni personalizzate

Per configurare il mapping delle rivendicazioni personalizzate, configura spec.authentication.oidc.attributeMapping in modo da definire eventuali mapping dall'IDToken del provider di identità originale. La chiave sarà il nome dell'attestazione nell'RCToken e il valore è un'espressione CEL su come analizzare l'attestazione da IDToken. Utilizza assertion per fare riferimento all'IDToken.

Esempio:

spec:
  authentication:
    oidc:
      attributeMapping:
        aud_copy: assertion.aud
        decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'

Nell'RCToken, un'attestazione nidificata attributes contiene le attestazioni che sono state configurate:

"attributes": {
    "aud_copy": "foo.googleusercontent.com",
    "decision": "success"
}

Se l'espressione CEL non riesce ad analizzare il valore da IDToken, ignorerà l'attestazione senza compromettere il flusso di autenticazione.

Upgrade delle autorizzazioni utente

Installa di nuovo i pacchetti di autenticazione utente poiché contengono il programma binario aggiornato per la nuova versione di autenticazione utente:
```
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 .
cd asm-user-auth/
```

Salva la configurazione del client OIDC:

export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

Esegui il deployment del servizio di autenticazione degli utenti per eseguire l'upgrade a una nuova versione.

Dettagli di configurazione dell'autenticazione utente

Nella tabella seguente sono descritti tutti i campi del CRD:

Nome campo	Descrizione
`authentication.oidc`	Questa sezione contiene la configurazione dell'endpoint OIDC e i parametri utilizzati nel flusso OIDC.
`authentication.oidc.certificateAuthorityData`	Questo è il certificato radice SSL del dominio del server di autorizzazione OIDC o il proxy HTTPS, se presente.
`authentication.oidc.oauthCredentialsSecret`	Riferimenti secret al secret di tipo opaco Kubernetes che contiene client_id OIDC OAuth2 e client_secret in payload JSON.
`authentication.oidc.issuerURI`	L'URI da utilizzare come emittente nell'RCToken di output.
`authentication.oidc.proxy`	Server proxy per l'IDP OIDC, se applicabile. Nel formato http://user:password@10.10.10.10:8888.
`authentication.oidc.redirectURIHost`	L'host da utilizzare per l'URI di terminazione OAuth. Se lasci vuoto questo campo, verrà utilizzato l'host dell'URL di destinazione e l'URI di reindirizzamento verrà assemblato in modo dinamico. Questo valore può essere utilizzato quando si vuole una sessione SSO di autenticazione utente in un dominio di livello superiore. Ad esempio, per abilitare l'accesso SSO tra profile.example.com/ e admin.example.com/, questo valore può essere impostato su example.com. Consente di stabilire una sessione di autenticazione utente su example.com e che verrà condivisa tra tutti i sottodomini. Nota: se più domini vengono pubblicati dallo stesso mesh, example1.com ed example2.com, la funzionalità non può essere utilizzata e ti consigliamo di lasciarla vuota.
`authentication.oidc.redirectURIPath`	Il percorso dell'endpoint in cui `authservice` terminerà il flusso OAuth. Devi registrare questo percorso URI e l'host come URI di reindirizzamento autorizzato nel server di autorizzazione per `authentication.oidc.clientID`. Inoltre, questo URI deve essere fornito dallo stesso mesh di servizi e dallo stesso traffico in entrata in cui è abilitato `authservice`.
`authentication.oidc.scopes`	L'ambito OAuth che deve essere richiesto nella richiesta di autenticazione. Elenco separato da virgole di identificatori utilizzati per specificare quali privilegi di accesso vengono richiesti oltre all'ambito "openid", ad esempio "groups,allatclaim".
`authentication.oidc.groupsClaim`	Se `idtoken` contiene un'attestazione di gruppi, utilizza questo campo per indicarne il nome. Se specificato, il servizio passerà i dati di questa rivendicazione all'attestazione `groups` nell'RCToken di output. Questa dichiarazione deve contenere un elenco di stringhe separate da virgole, ad esempio ["gruppo1", "gruppo2"].
`authentication.oidc.attributeMapping`	Contiene una o più mappature delle attestazioni di `idtoken` espressioni CEL seguite. Tutte le rivendicazioni devono fare riferimento a `assertion.X`, `assertion` fa riferimento all'IDToken originale, ad esempio `aud_copy: assertion.aud.`
`authentication.outputJWTAudience`	Il segmento di pubblico dell'RCToken generato da `authservice`. I file collaterali possono convalidare l'RCToken in entrata in base a questo valore del pubblico.

Risolvere i problemi

Accessibilità della rete all'IdP.

Possibile log: error: TLS handshake failed..

Verifica eseguendo curl dal container istio-proxy all'URI dell'emittente IDP. Se non riesce a connettersi, l'utente può controllare le regole firewall o altre configurazioni di rete per il cluster.
Certificato CA radice.

Possibile log: error: The server's TLS certificate did not match expectations. o error: TLS handshake failed..

Assicurati che certificateAuthorityData contenga il certificato CA radice corretto. Se non esiste un proxy HTTPS che termina il traffico HTTPS, questo dovrebbe contenere il certificato CA radice per l'IdP. Se invece è presente, dovrebbe contenere quello del proxy.
Configurazione del percorso di reindirizzamento.

Possibile osservazione: ricevi la pagina di errore 404 durante il flusso di autenticazione OIDC.

Autorizzazione utente restituisce l'intestazione "Set-Cookie" senza utilizzare l'attributo percorso, che per impostazione predefinita il browser utilizza la directory dell'URL della richiesta come percorso del cookie (ambito del cookie relativo al percorso). Pertanto ti consigliamo di non includere "/" nel percorso di reindirizzamento, a meno che non sia previsto.
Il file collaterale non è in grado di recuperare jwksUri.

In alcuni scenari, una limitazione relativa al file collaterale potrebbe comportare il mancato recupero di jwksUri. Se lo spazio dei nomi non è presente utilizzando un carattere jolly (ad esempio, ./* o istio-system/*), non funzionerà. Devi aggiungere manualmente lo spazio dei nomi nel file collaterale in uscita.

Domande frequenti

Come faccio a eseguire l'upgrade di Anthos Service Mesh con l'autenticazione utente abilitata?

Se utilizzi Anthos Service Mesh in-cluster, segui il processo di upgrade Anthos Service Mesh e specifica il file overlay aggiungendo --custom_overlay user-auth-overlay.yaml a asmcli install nella riga di comando.

L'upgrade di Anthos Service Mesh gestito viene eseguito automaticamente.
Quanta CPU e memoria devo eseguire il provisioning per authservice? E quante richieste al secondo può gestire?

Per impostazione predefinita, authservice è configurato con 2, 0 vCPU e 256 Mi di memoria. Con questa configurazione, authservice è in grado di gestire 500 richieste al secondo. Per gestire quantità maggiori di richieste, devi eseguire il provisioning di più CPU, che è approssimativamente proporzionale alla sua capacità di gestione delle richieste. Puoi anche configurare più repliche di authservice per aumentare la scalabilità orizzontale.