Stai visualizzando la documentazione di Service Mesh 1.21.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare l'autenticazione utente di Cloud Service Mesh

Se hai TRAFFIC_DIRECTOR l'implementazione del piano di controllo, questa funzionalità è supportata solo dalla lista consentita. Contatta l'assistenza per richiedere l'accesso.

L'autenticazione utente di Cloud Service Mesh è una soluzione integrata per l'autenticazione degli utenti finali basata su browser e il controllo dell'accesso ai carichi di lavoro di cui è stato eseguito il deployment. Ti consente di integrarti con gli Identity Provider (IDP) esistenti per l'autenticazione degli utenti e utilizza le API e i criteri di autorizzazione di Istio per la gestione dell'accesso. È un'alternativa user-friendly all'autenticazione JWT (JSON Web Token) di Istio.

Un caso d'uso tipico è quando un'organizzazione utilizza Cloud Service Mesh per ospitare un'applicazione web a cui la sua forza lavoro può accedere tramite un browser web. Inoltre, l'organizzazione deve utilizzare il proprio provider di identità esistente per gestire gli utenti le identità di altro tipo. L'autenticazione utente di Cloud Service Mesh semplifica l'autenticazione degli utenti tramite un flusso di accesso e consenso OpenID Connect (OIDC) web standard. Quando l'utente esegue l'autenticazione, Cloud Service Mesh applica Istio di autorizzazione e, se l'autorizzazione ha avuto esito positivo, trasmette l'identità ai carichi di lavoro in un formato delle credenziali sicure.

Come funziona

L'autenticazione utente di Cloud Service Mesh introduce un nuovo componente, authservice. Questo componente si integra con l'ingress basato su Envoy come servizio di autorizzazione esterno che intercetta tutte le richieste in arrivo per l'autenticazione. authservice implementa il lato client del protocollo OIDC e consente agli utenti di accedere alle applicazioni tramite un browser, dove 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 fornitore 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 viene inoltrato al livello di autorizzazione Istio nell'ingress. Questo modello fornisce il controllo dell'accesso perimetrale per il traffico nella rete. Se l'utente è autorizzato ad accedere a una risorsa, questo token RC viene anche inoltrato ai microservizi per ottenere informazioni sull'entità e applicare un controllo dell'accesso granulare.

Il seguente diagramma mostra la posizione di authservice nel mesh e il modo in cui si riferisce alle altre parti del mesh, come il traffico in entrata, i carichi di lavoro, browser e a qualsiasi IdP esistente.

autenticazione dell'utente finale

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

Installa il servizio di autenticazione degli utenti

I passaggi riportati di seguito spiegano come configurare authservice.

Prerequisiti

Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster. a:

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

Inoltre, assicurati di soddisfare i prerequisiti utilizzando il seguente passaggi.

Personalizza l'overlay di installazione dell'autenticazione utente

Per installare il servizio di autenticazione degli utenti, devi personalizzare Cloud Service Mesh per aggiungere un provider di autorizzazione esterno a livello di mesh. I passaggi necessari dipendono dal fatto che tu stia utilizzando Cloud Service Mesh gestito o in-cluster.

Gestito

Aggiorna il ConfigMap per includere il mesh di autenticazione utente. Nel comando seguente, usa lo stesso REVISION_LABEL usato quando eseguire il provisioning di Cloud Service Mesh gestito (ad esempio, asm-managed, asm-managed-rapid, o asm-managed-stable):
```
kubectl edit configmap istio-REVISION_LABEL -n istio-system
```

Aggiungi il seguente testo sotto il campo mesh in MeshConfig:

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

Crea lo spazio dei nomi asm-user-auth.
```
kubectl create namespace asm-user-auth
```
Attiva lo spazio dei nomi per l'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
```
kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite
```
Gestito (Istiod)
Consigliato: esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
```
```sh
kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite
```
```
Se sei un utente esistente con il piano di controllo Managed Istiod: Ti consigliamo di usare l'inserimento predefinito, ma l'inserimento basato sulle revisioni supportati. Segui le istruzioni riportate di seguito:
1. Esegui questo comando per individuare i canali di rilascio disponibili:
```
kubectl -n istio-system get controlplanerevision
```
L'output è simile al seguente:
```
NAME                AGE
asm-managed-rapid   6d7h
```
Nota: se nell'elenco riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. Avere più canali del piano di controllo nel cluster non è supportato.

Nell'output, il valore sotto la colonna NAME è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.
1. Applica l'etichetta di revisione allo spazio dei nomi:
  kubectl label namespace asm-user-auth \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
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 posizione del repository anthos-service-mesh-packages sul computer. Se non hai questo repository sulla tua macchina, clonalo: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

Nel cluster

Ottieni l'esempio overlay autenticazione utente e aggiornalo se ci sono personalizzazioni nella tua rete mesh. È una best practice consigliata gestire questo file overlay nel controllo delle versioni.
```
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 Cloud Service Mesh con overlay per utilizzare uno script fornito da Google per installare Cloud 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 l'opzione --custom_overlay include tutti i file di overlay.

I pacchetti kpt di autenticazione utente creano un AuthorizationPolicy per fare riferimento al provider di autorizzazione esterno specificato da pkg/ext-authz.yaml.
Crea lo spazio dei nomi asm-user-auth.
```
kubectl create namespace asm-user-auth
```
Attiva lo spazio dei nomi per l'iniezione.

Consigliato: esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
```
  kubectl label namespace asm-user-auth \
      istio.io/rev- istio-injection=enabled --overwrite
```
Ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulle revisioni: segui le istruzioni riportate di seguito:
1. Utilizza il seguente comando per individuare l'etichetta di revisione su istiod:
```
kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
```
2. Applica l'etichetta di revisione allo spazio dei nomi. Nel seguente comando, REVISION_LABEL è il valore dell'etichetta della revisione istiod che hai annotato nel passaggio precedente.
```
kubectl label namespace asm-user-auth \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite
```
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 posizione del repository anthos-service-mesh-packages sul computer. 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

Imposta la configurazione del client OIDC seguendo questi passaggi. Questa guida utilizza Google come provider di identità, ma puoi utilizzare qualsiasi provider di identità che supporti l'autenticazione OIDC.

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

Vai a credenziali
Vai a Crea credenziali e scegli ID client OAuth. Se necessario, imposta le opzioni della schermata per il 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 puoi 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

Ottieni i `kpt` pacchetti

Segui i passaggi riportati di seguito per installare la configurazione authservice consigliata dal repository pubblico. Questi comandi recuperano l'ultimo container authservice e lo avviano come pod nello spazio dei nomi asm-user-auth. Inoltre, configura il traffico in entrata per intercettare tutti richieste.

Scarica il pacchetto kpt:

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 .
cd asm-user-auth/

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

OAuth2 richiede un URL di reindirizzamento ospitato su un endpoint protetto da HTTPS. Questi comandi sono solo a scopo di esempio e semplificano la configurazione generando un certificato autofirmato per il gateway di ingresso 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 per ospitare il traffico HTTPS:

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

Applica le chiavi di crittografia e firma

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

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

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

Prepara la chiave di crittografia della sessione con il seguente formato o utilizza l'esempio del pacchetto, che puoi visualizzare tramite cat ./samples/cookie_encryption_key.json.

{
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "K":"YOUR_KEY",
        "useAfter": 1612813735
     }
  ]
}

Puoi generare una chiave AES di test con il seguente comando:

openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key

Prepara la chiave di firma RCToken con il seguente formato o utilizza il sample del pacchetto, che puoi visualizzare tramite cat ./samples/rctoken_signing_key.json.

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

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

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

Crea il secret Kubernetes, che authservice monterà nel proprio sistema file.

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

esegui il deployment del servizio di autenticazione degli utenti

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

Imposta i valori necessari per la configurazione dell'autenticazione utente. L'ID client e il secret vengono archiviati come secret di Kubernetes, quindi utilizziamo Base64 per codificarli. Visita il repository pubblico per visualizzare tutti i settati 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 degli utenti finali. UserAuthConfig è configurabile in fase di esecuzione e puoi actualizarlo per modificare il comportamento di authservice e configurarlo con gli endpoint per qualsiasi server di autorizzazione OIDC.

Puoi visualizzare il file cat pkg/user_auth_config.yaml, che 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}

Consulta: dettagli di configurazione dell'autenticazione utente per descrizioni dettagliate dei campi user_auth_config.yaml.

Esegui attività di post-installazione

Dopo aver completato l'installazione precedente, dovrai eseguire le seguenti attività passaggi.

Attivare l'autenticazione utente per le applicazioni

Questa sezione mostra come attivare l'autenticazione utente utilizzando httpbin come esempio.

L'autenticazione utente di Cloud Service Mesh utilizza un protocollo CUSTOM del criterio di autorizzazione digitata per attivare il flusso OIDC.

Dopo aver ottenuto ha installato il gateway Istio, configuralo per gestire il traffico HTTPS utilizzando il certificato TLS userauth-tls-cert che hai creato sopra. Di seguito è riportata la configurazione di 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 deployment di machine learning.
```
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 gestire il traffico HTTPS e utilizzare la porta 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 ingresso sulla porta 8443 verrà inoltrato a localhost per rendere l'applicazione accessibile localmente.

Esegui il deployment di samples/rctoken-authz.yaml per consentire a RequestAuthentication e AuthorizationPolicy di verificare il token RC per le richieste.

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

Esempio di 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

Verifica l'autenticazione degli utenti

httpbin gestisce due percorsi: /ip è accessibile pubblicamente e /headers richiede che l'utente finale acceda tramite il proprio IdP configurato.

Per verificare di poter accedere direttamente a /ip, visita https://localhost:8443/ip.
Verifica che sia visualizzata la pagina di accesso OIDC visitando https://localhost:8443/headers.
Dopo aver eseguito l'accesso, fai clic su Avanti e verifica che ti reindirizzi al /headers.

Configurare i criteri di autorizzazione

Dopo aver completato la configurazione nei passaggi precedenti, ogni utente reindirizzate tramite un flusso di autenticazione basato sul web. Al termine del flusso, authservice genera un RCToken in formato JWT, che utilizza per trasmettere le informazioni sull'utente autenticato.

Aggiungi i criteri di autorizzazione Istio all'ingresso per assicurarti 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 di ingresso per convalidare il token RC emesso da authservice e concede l'autorizzazione solo quando il JWT contiene i campi desiderati, come 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 dell'ambiente

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

Inoltre, assicurati che certificateAuthorityData abbia il certificato radice previsto contenuti. Ad esempio, se l'IDP è attendibile con i certificati principali del sistema, puoi lasciare il campo vuoto. Se è presente un proxy HTTPS che termina la connessione HTTPS, deve essere impostato sul certificato principale del proxy.

Gestisci e ruota le chiavi

Esistono due set di chiavi utilizzati da authservice. Puoi ruotare ogni tasto indipendentemente. Tuttavia, prima di ruotare le chiavi, è importante a capire come funziona la rotazione.

Entrambe le chiavi sono in formato JSON. Il campo useAfter specifica il timestamp da quando la chiave verrà considerata in uso. Durante la rotazione della chiave, includere chiavi vecchie e nuove nel file JSON. Ad esempio, nel seguente ad esempio, 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
      }
   ]
}

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

La coppia di chiavi pubblica/privata viene utilizzata per firmare RCToken. La chiave pubblica è trasmesso ai file collaterali da istiod per la verifica JWT. È fondamentale per file collaterali per ricevere la nuova chiave pubblica prima che authservice inizi a utilizzare la nuova chiave privata per firmare RCToken. A questo scopo, authservice inizia a pubblicare la chiave pubblica subito dopo l'aggiunta, ma attende una di tempo prima di iniziare a utilizzarlo per firmare RCToken.

Per riassumere, quando esegui rotazioni delle chiavi è consigliabile:

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

Deployment multi-cluster

L'autenticazione utente di Cloud Service Mesh supporta il deployment multi-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 secret client 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 una delle authservice istanze. Puoi utilizzare la regola di destinazione per configurare il gateway di ingresso in modo che invii le richieste al authservice nello stesso cluster e il failover solo al 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 le altre configurazioni, questa deve essere configurata in ogni cluster.

Mapping delle rivendicazioni personalizzate

Per configurare la mappatura delle attestazioni personalizzate, configura spec.authentication.oidc.attributeMapping per definire eventuali mappature dall'ID token del provider di identità originale. La chiave sarà la dichiarazione in RCToken e il valore è un'espressione CEL su come analizzare la richiesta da IDToken, usa 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'affermazione nidificata attributes contiene le affermazioni configurate:

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

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

Upgrade dell'autenticazione utente

Installa di nuovo i pacchetti user-auth, in quanto contengono il file binario aggiornato per la nuova versione di user-auth:
```
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 utente per eseguire l'upgrade a una nuova versione.

Dettagli sulla configurazione dell'autenticazione utente

Nella tabella seguente sono descritti tutti i campi della 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 dell'autorizzazione OIDC server web o proxy HTTPS, se presente.
`authentication.oidc.oauthCredentialsSecret`	Riferimenti ai secret di tipo Opaque di Kubernetes che contengono client_id e client_secret di OAuth2 OIDC nel payload JSON.
`authentication.oidc.issuerURI`	L'URI da utilizzare come emittente nell'RCToken di output.
`authentication.oidc.proxy`	Server proxy all'IdP OIDC, se applicabile. Con il 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, l'host verrà utilizzato l'URL di destinazione e l'URI di reindirizzamento verrà assemblato in modo dinamico. Questo valore può essere utilizzato quando è richiesta una sessione SSO di autenticazione utente in un dominio di livello superiore. Ad esempio, per attivare SSO tra profile.example.com/ e admin.example.com/, questo valore può essere impostato su example.com. Attiverà l'autenticazione utente verrà stabilita all'indirizzo example.com e verrà condivisa tra tutti i sottodomini. Nota: se vengono pubblicati più domini dalla stessa mesh, ad esempio example1.com ed example2.com, la funzionalità non può essere utilizzata e consigliamo di lasciarla vuota.
`authentication.oidc.redirectURIPath`	Il percorso dell'endpoint in cui `authservice` terminerà il flusso OAuth. Tu registrare questo percorso URI più l'host come URI di reindirizzamento autorizzato nella server di autorizzazione per `authentication.oidc.clientID`. Inoltre, questo URI deve essere pubblicato dallo stesso servizio mesh e dall'ingress 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 l'accesso oltre a "openid" ambito, ad esempio "groups,allatclaim".
`authentication.oidc.groupsClaim`	Se `idtoken` contiene un'attestazione di gruppi, utilizza questo campo per indicare il nome. Se specificato, il servizio trasmetterà i dati in questo nell'attestazione `groups` nell'RCToken di output. Questa rivendicazione deve contenere un elenco di stringhe separate da virgole, ad es. ["gruppo1", "gruppo2"].
`authentication.oidc.attributeMapping`	Contiene una o più mappature dei claim da `idtoken` seguite da espressioni CEL. A tutti i claim deve essere fatto riferimento tramite `assertion.X`, mentre `assertion` fa riferimento all'IDToken originale, ad esempio `aud_copy: assertion.aud.`
`authentication.outputJWTAudience`	Il pubblico dell'RCToken generato da `authservice`. I file collaterali possono convalidare l'RCToken in entrata in base a questo valore del pubblico.

Risoluzione dei problemi

Accessibilità di rete agli IdP.

Possibile log: error: TLS handshake failed..

Verifica eseguendo curl dal contenitore temporaneo collegato a istio-proxy per chiamare URI emittente dell'IDP. Ad esempio, consulta Raccogliere i log di Cloud Service Mesh.

Se non riesci a connetterti, controlla le regole del firewall o altre configurazioni di rete per il cluster.
Certificato CA radice.

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

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

Possibile osservazione: ricezione di una pagina di errore 404 durante il flusso di autenticazione OIDC.

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

In alcuni scenari, una correlato la limitazione potrebbe causare il mancato recupero di jwksUri. Se lo spazio dei nomi è non presente utilizzando un carattere jolly (ad esempio, ./* o istio-system/*), quindi questa operazione non funzionerà. Devi aggiungere manualmente il relativo spazio dei nomi nel traffico in uscita di terze parti.

Domande frequenti

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

Segui la procedura di upgrade di Cloud Service Mesh e specifica il file overlay aggiungendo --custom_overlay user-auth-overlay.yaml sulla riga di comando a asmcli install.
Quante risorse dobbiamo fornire per authservice? E quanti richieste al secondo che può gestire?

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