Configurazione dell'autenticazione utente per Anthos Service Mesh

L'autenticazione utente di 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 utente 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 si verifica quando un'organizzazione usa 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 semplifica l'autenticazione degli utenti mediante un flusso di accesso e consenso standard OpenID Connect (OIDC) basato sul web. Quando l'utente esegue l'autenticazione, Anthos Service Mesh applica i criteri di autorizzazione di Istio e, in caso di autorizzazione riuscita, trasmette l'identità ai carichi di lavoro in un formato 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 in entrata per l'autenticazione. 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 interattivo di autenticazione e consenso per stabilire una sessione di breve durata. authservice implementa protocolli standard del settore per l'integrazione con qualsiasi provider di identità che possa 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 le informazioni principali e applicare controllo dell'accesso granulare.

Il seguente diagramma mostra la posizione di authservice nel mesh e la sua relazione con le altre parti del mesh, come il traffico in entrata, i carichi di lavoro, il browser dell'utente e qualsiasi IdP esistente.

autenticazione degli utenti finali

Gli amministratori possono installare authservice come componente aggiuntivo su un'installazione di Anthos Service Mesh. Se 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 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 questi passaggi per assicurarti di soddisfare i prerequisiti.

Personalizzare l'installazione utilizzando l'overlay di autenticazione dell'utente

Per installare il servizio di autenticazione degli utenti, devi personalizzare l'installazione di ASM in modo da aggiungere un provider di autorizzazione esterno a livello di mesh.

  1. Scarica l'overlay di autorizzazione utente di esempio e aggiornalo in caso di personalizzazioni nella rete mesh. Come best practice consigliata, conserva questo file overlay nel controllo del codice sorgente.

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/release-1.0/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml

  2. Segui la procedura di installazione di ASM con overlay per utilizzare uno script fornito da Google per installare Anthos Service Mesh con l'overlay di autenticazione utente. Ad esempio:

    /install_asm \
 --project_id "PROJECT_ID" \
 --cluster_name "CLUSTER_NAME" \
 --cluster_location "CLUSTER_LOCATION" \
 --mode install \
 --enable_all \
 --custom_overlay user-auth-overlay.yaml

    Il pacchetto di autenticazione degli utenti kpt crea un AuthorizationPolicy per fare riferimento al provider di autorizzazioni esterno specificato da pkg/ext-authz.yaml.

Prepara la configurazione del client OIDC

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

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

    Vai a Credenziali

  2. 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://localhost:8443/_gcp_anthos_callback.

    Quindi, fai clic su Salva.

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

    export OIDC_CLIENT_ID='<your-client-id>'
export OIDC_CLIENT_SECRET='<your-client-secret>'
export OIDC_ISSUER_URI='https://accounts.google.com'
# The host where your application is served from, such as https://example.com
export OIDC_REDIRECT_HOST='<your-oidc-redirect-host>'
export OIDC_REDIRECT_PATH='<your-oidc-redirect-path>'

Ricevi i pacchetti di kpt

Segui questi passaggi per installare la configurazione authservice consigliata dal repository pubblico. Questi comandi recuperano il container authservice più recente e lo avviano come pod nello spazio dei nomi asm-user-auth. Configura inoltre il traffico in entrata per intercettare tutte le richieste.

  1. Ottieni il pacchetto kpt:

    kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth@release-1.0 .
cd asm-user-auth/

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

OAuth2 richiede un URL di reindirizzamento ospitato su un endpoint con protezione HTTPS. Questi comandi sono a scopo di esempio e semplificano la configurazione generando un certificato autofirmato per il gateway in entrata Istio. Un deployment di produzione non deve utilizzare certificati autofirmati.

  1. Genera un certificato autofirmato:

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

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

    kubectl create -n istio-system secret tls userauth-tls-cert --key=key.pem \
--cert=cert.pem

Applica le chiavi di crittografia e firma

L'authservice ha bisogno di due mazzi 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 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 dell'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.

  1. Dopo aver generato le chiavi, inserisci i relativi dati nello stesso formato:

    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
     }
  ]
}

    cat ./samples/cookie_encryption_key.json
{
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "K":"YOUR_KEY",
        "useAfter": 1612813735
     }
  ]
}

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

    Puoi trovare il valore dell'etichetta REVISION controllando Deployment di Istio.

    kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
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 degli utenti e il deployment nello spazio dei nomi asm-user-auth.

  1. Imposta le variabili oauth. L'ID client e il secret sono archiviati come secret di Kubernetes, quindi usiamo Base64 per codificarli.

    kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientID $(echo -n ${OIDC_CLIENT_ID} | base64 -w0)
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientSecret $(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.issuerURI ${OIDC_ISSUER_URI}
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIHost ${OIDC_REDIRECT_HOST}
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIPath ${OIDC_REDIRECT_PATH}

  2. 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 endpoint per qualsiasi server di autorizzazione OIDC. Contiene i seguenti campi:

cat pkg/user_auth_config.yaml

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""
      oauthCredentialsSecret:
        name: "oauth-secret"
        namespace: "asm-user-auth"
      issuerURI: "https://accounts.google.com"
      redirectURIHost: ""
      redirectURIPath: "/_gcp_asm/authenticate"

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

Eseguire attività post-installazione

Le attività seguenti sono necessarie dopo aver completato i precedenti passaggi di installazione.

Attivare l'autenticazione utente per le applicazioni

Questa sezione illustra come abilitare l'autenticazione utente utilizzando come esempio l'applicazione di esempio Boutique online.

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

Il processo di installazione crea anche un gateway Istio per gestire il traffico HTTPS utilizzando il certificato TLS userauth-tls-cert che hai creato in precedenza. Ecco la configurazione di pkg/gateway.yaml.

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

  1. Aggiorna l'applicazione Boutique online in modo da utilizzare questo gateway per gestire il traffico HTTPS e utilizza il port forwarding per accedere all'applicazione in locale:

    kubectl apply -f./samples/boutique-route.yaml -n demo
kubectl port-forward service/istio-ingressgateway 8443:443 -n istio-system

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

  2. Verifica che l'applicazione di esempio di Online Boutique sia accessibile all'indirizzo https://localhost:8443/.

Verificare l'autenticazione degli utenti

I servizi dell'applicazione Boutique online ora richiedono all'utente finale di eseguire l'accesso tramite il proprio account Google.

  1. Verifica che sia visualizzata la pagina di accesso OIDC visitando https://localhost:8443/.

  2. Dopo aver effettuato l'accesso, fai clic su Avanti e verifica che il reindirizzamento venga reindirizzato alla home page di Boutique online.

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 termine del flusso, authservice genererà un RCToken in formato JWT, che usa per trasmettere le informazioni utente autenticate.

  1. Aggiungi i criteri di autorizzazione Istio in entrata per garantire che venga eseguito un controllo dell'autorizzazione per ogni utente autenticato:

    kubectl apply -f ./samples/rctoken-authz.yaml

  2. Il file rctoken-authz.yaml configura il gateway in entrata per convalidare il token RC emesso da authservice e concedere l'autorizzazione 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: RequestAuthentication
metadata:
 name: require-rc-token
 namespace: istio-system
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
 namespace: istio-system
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

Configura le impostazioni specifiche per l'ambiente

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

Inoltre, assicurati che per i valori tokenEndpoint e authorizationEndpoint configurati nel CRD UserAuthConfig sia stata configurata una route in VirtualService. I precedenti passaggi di installazione lo hanno impostato in asm-user-auth/userauth-oidc VirtualService.

Gestisci e ruota le chiavi

authservice utilizza due coppie di chiavi. 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 verrà considerata in uso. Durante una rotazione della chiave, devi includere sia le chiavi vecchie che nuove nel JSON. Ad esempio, nel seguente 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
      }
   ]
}

Anthos Service Mesh utilizza la chiave simmetrica per criptare i dati della sessione memorizzati nei cookie del browser. Per garantire la validità delle sessioni esistenti, authservice tenta la decrittografia con tutte le chiavi nel set di chiavi. In 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.

Per riassumere, quando esegui rotazioni delle chiavi consigliamo di:

  1. Esegui rotazioni delle chiavi regolari o on demand in base alle tue esigenze.
  2. Nel formato JSON, includi sia la chiave attuale 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.
  3. Monitora e conferma che i servizi siano ancora in stato integro dopo l'utilizzo della nuova chiave. Attendi almeno un giorno dall'utilizzo della nuova chiave prima di andare al passaggio successivo.
  4. Rimuovi le vecchie chiavi dalle voci JSON. Non sono più necessari.

Dettagli di configurazione dell'autenticazione utente

Nella tabella seguente vengono 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 SSL del dominio del server di autorizzazione OIDC.
authentication.oidc.clientSecret Tsecret fa riferimento al secret di tipo Kubernetes Opaque che contiene client_id OIDC OAuth2 e client_secret nel payload JSON.
authentication.oidc.issuerURI L'URI da utilizzare come emittente nell'RCToken di output.
authentication.oidc.redirectURIHost L'host da utilizzare per l'URI di terminazione OAuth. Se lasci questo campo vuoto, verrà utilizzato l'host dell'URL di destinazione e l'URI di reindirizzamento verrà assemblato dinamicamente.
Questo valore può essere utilizzato quando si desidera una sessione SSO di autenticazione utente su un dominio di livello superiore. Ad esempio, per abilitare il servizio SSO tra profile.example.com/ e admin.example.com/, questo valore può essere impostato su example.com. In questo modo, verrà creata una sessione di autorizzazione utente su example.com, che verrà condivisa tra tutti i sottodomini. Nota: se lo stesso mesh (example1.com ed example2.com) gestisce più domini, la funzionalità non può essere utilizzata ed è consigliabile lasciarla vuota.
authentication.oidc.redirectURIPath Il percorso dell'endpoint in cui "authservice" termina 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.
authentication.oidc.groupsClaim Se "idtoken" contiene un'attestazione di gruppi, utilizza questo campo per indicarne il nome. Se specificato, il servizio trasferisce i dati in questa richiesta nell'attestazione 'groups' nell'RCToken di output.
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.

Deployment 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, ad esempio la risorsa personalizzata UserAuth, il client secret OIDC e le chiavi di crittografia, deve essere tutte replicata in ciascun cluster.

Per impostazione predefinita, il gateway in entrata bilancia il carico delle richieste di autenticazione verso una qualsiasi delle istanze authservice. Puoi utilizzare la regola di destinazione per configurare il gateway in entrata al fine di inviare richieste a authservice nello stesso cluster e solo eseguire il failover 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 configurazione deve essere configurata in ogni cluster.

Domande frequenti

  1. Come faccio a eseguire l'upgrade di Anthos Service Mesh con Autenticazione utente abilitata?

    Segui il processo di upgrade di Anthos Service Mesh e specifica il file di overlay user-auth.yaml nella riga di comando per install_asm.

  2. Di quante risorse dobbiamo eseguire il provisioning per authservice? E quante richieste al secondo è in grado di gestire?

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