Configurazione dell'autenticazione utente di Cloud Service Mesh
Se utilizzi questa implementazione, devi apportare modifiche nel configmapistio-asm-managed-rapid
, anche se utilizzi un canale
diverso da quello rapido.
Se hai l'TRAFFIC_DIRECTOR
implementazione del control plane, 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 utente finale basata su browser e controllo dell'accesso ai carichi di lavoro di cui è stato eseguito il deployment. Consente l'integrazione con i provider di identità (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 facile da usare all'autenticazione con token web JSON (JWT) di Istio.
Un caso d'uso tipico si verifica quando un'organizzazione utilizza Cloud Service Mesh per ospitare un'applicazione web a cui i dipendenti possono accedere tramite un browser web. Inoltre, l'organizzazione deve utilizzare il proprio provider di identità esistente per gestire le identità utente. L'autenticazione utente di Cloud Service Mesh consente agli utenti di autenticarsi facilmente utilizzando un flusso di accesso e consenso OpenID Connect (OIDC) standard basato sul web. Quando l'utente esegue l'autenticazione, Cloud Service Mesh applica i criteri di autorizzazione Istio e, in caso di autorizzazione riuscita, trasmette l'identità ai carichi di lavoro in un formato di credenziali sicuro.
Come funziona
L'autenticazione utente di Cloud Service Mesh introduce un nuovo componente, authservice
.
Questo componente si integra con l'ingresso basato su Envoy come servizio di autorizzazione esterno che intercetta tutte le richieste in entrata per l'autenticazione. authservice
implementa il lato client del protocollo OIDC
e consente l'accesso degli utenti 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 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 sul principal vengono incapsulate in un RCToken
in formato JWT,
firmato da authservice
, che le inoltra al livello di autorizzazione Istio
nell'ingresso. Questo modello fornisce controllo dell'accesso perimetrale per il traffico
nella mesh. Se l'utente è autorizzato ad accedere a una risorsa, questo RCToken viene
inoltrato anche ai microservizi per ottenere informazioni sull'entità e applicarecontrollo dell'accessoso granulare.
Il seguente diagramma mostra la posizione di authservice
nel mesh e il suo rapporto con le altre parti del mesh, come l'ingresso, i carichi di lavoro, il browser dell'utente e qualsiasi IDP esistente.
Gli amministratori possono installare authservice
come componente aggiuntivo su un'installazione di Cloud Service Mesh. 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 sull'ingresso.
Installare il servizio di autenticazione utente
I passaggi seguenti spiegano come configurare authservice
.
Prerequisiti
Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster per:- Installare gli strumenti richiesti
- Scarica
asmcli
- Concedere le autorizzazioni di amministratore del cluster
- Convalidare il progetto e il cluster
- Se utilizzi Cloud Service Mesh gestito su un cluster privato, assicurati che il cluster sia in grado di inviare traffico in uscita all'IdP.
Inoltre, assicurati di soddisfare i prerequisiti seguendo i passaggi riportati di seguito.
Personalizzare la sovrapposizione di autenticazione utente dell'installazione
Per installare il servizio di autenticazione utente, devi personalizzare l'installazione di Cloud Service Mesh per aggiungere un provider di autorizzazione esterno a livello di mesh. I passaggi richiesti dipendono dal fatto che tu stia utilizzando Cloud Service Mesh gestito o in-cluster.
Gestito
Aggiorna ConfigMap in modo da includere MeshConfig per l'autenticazione utente. Nel comando seguente, utilizza lo stesso
REVISION_LABEL
che hai utilizzato durante il provisioning di Cloud Service Mesh gestito (ad esempio,asm-managed
,asm-managed-rapid
, oasm-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'inserimento. I passaggi dipendono dall'implementazione del control plane.
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 Istiod gestito: ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulla revisione. Segui queste istruzioni:
- 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
Nell'output, il valore nella colonna
NAME
è l'etichetta della revisione corrispondente al canale di rilascio disponibile per la versione di Cloud Service Mesh.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
In-cluster
Scarica l'esempio di overlay di autenticazione utente e aggiornalo se sono presenti personalizzazioni nel mesh. È una best practice consigliata mantenere 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 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
I pacchetti di autenticazione utente
kpt
creano unAuthorizationPolicy
per fare riferimento al provider di autorizzazione esterno specificato dapkg/ext-authz.yaml
.Crea lo spazio dei nomi
asm-user-auth
.kubectl create namespace asm-user-auth
Attiva lo spazio dei nomi per l'inserimento.
Consigliato:esegui questo 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 sulla revisione: Segui queste istruzioni:
Utilizza il seguente comando per individuare l'etichetta della revisione su
istiod
:kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
Applica l'etichetta di revisione allo spazio dei nomi. Nel seguente comando,
REVISION_LABEL
è il valore dell'etichetta di revisioneistiod
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
Preparare 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.
Nella Google Cloud console, vai ad API e servizi > Credenziali.
Vai a Crea credenziali, poi 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 potresti impostarehttps://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 pacchetti kpt
Per installare la configurazione authservice
consigliata
dal
repository pubblico, segui questi passaggi. Questi
comandi recuperano l'ultimo container authservice
e lo avviano come pod nello
spazio dei nomi asm-user-auth
. Inoltre, configura l'ingresso per intercettare tutte
le 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 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 esemplificativo 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 per ospitare 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
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 insieme di chiavi è una coppia di chiave pubblica/privata. Questa chiave viene utilizzata per firmare le informazioni dell'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 kpt
di autenticazione utente 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 l'esempio 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 test 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
verrà montato 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
Esegui il deployment del servizio di autenticazione utente
I seguenti comandi 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 vengono archiviati come secret di Kubernetes, pertanto utilizziamo 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 fase di runtime e puoi
aggiornarlo per modificare il comportamento di authservice
e configurarlo con endpoint
per qualsiasi server di autorizzazione OIDC.
Puoi visualizzare il file per 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}
Per descrizioni dettagliate dei campi user_auth_config.yaml
, consulta
Dettagli della configurazione dell'autenticazione utente.
Esegui le attività post-installazione
Le seguenti attività sono richieste dopo aver completato i passaggi di installazione precedenti.
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 criterio di autorizzazione
CUSTOM
digitato per attivare il flusso OIDC.
Dopo aver installato il gateway Istio, configurarlo per gestire il traffico HTTPS utilizzando il certificato TLS userauth-tls-cert
creato in precedenza. 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 attivare l'inserimento automatico diistio-proxy
per i deployment.kubectl label namespace default istio.io/rev=REVISION --overwrite
Esegui il deployment di
httpbin
nello spazio dei nomidefault
.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 utilizza l'inoltro delle porte 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
Il gateway in entrata sulla porta 8443 verrà inoltrato a
localhost
per rendere l'applicazione accessibile localmente.Esegui il deployment di
samples/rctoken-authz.yaml
per attivare 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
httpbin
gestisce due percorsi: /ip
è accessibile pubblicamente e /headers
richiede all'utente finale di accedere tramite il proprio IdP configurato.
Verifica di poter accedere direttamente a
/ip
visitandohttps://localhost:8443/ip
.Verifica di visualizzare la pagina di accesso OIDC visitando
https://localhost:8443/headers
.Dopo aver eseguito l'accesso, fai clic su Avanti e verifica che venga visualizzata la pagina
/headers
.
Configurare 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, il
authservice
genererà un RCToken
in formato JWT, che utilizza per
trasmettere le informazioni dell'utente autenticato.
Aggiungi 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 autorizza solo quando il JWT contiene i campi desiderati, come pubblico e 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.
Configurare le impostazioni specifiche dell'ambiente
I passaggi precedenti utilizzano localhost
e un certificato HTTPS autofirmato per una configurazione rapida. Per l'utilizzo reale in produzione, utilizza il tuo dominio, ad esempio example.com
.
Inoltre, assicurati che certificateAuthorityData
contenga il certificato radice previsto. Ad esempio, se l'IDP è considerato attendibile con i certificati root del sistema, puoi
lasciare vuoto questo campo. Se è presente un proxy HTTPS che termina la connessione HTTPS, deve essere impostato sul certificato radice del proxy.
Gestire e ruotare le chiavi
authservice
utilizza due mazzi 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 a partire dal quale
la chiave verrà considerata da utilizzare. Durante la rotazione di una chiave, devi
includere sia la chiave precedente sia quella nuova nel file 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
}
]
}
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 decriptazione con tutte le chiavi nel set di chiavi. Durante la 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 sidecar da istiod
per la verifica JWT. È fondamentale che i
sidecar ricevano 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 immediatamente dopo l'aggiunta, ma attende un periodo di tempo
significativo prima di iniziare a utilizzarla per firmare RCToken
.
Per riassumere, quando esegui la rotazione delle chiavi, ti consigliamo di:
- Esegui rotazioni delle chiavi regolari o su richiesta in base alle tue esigenze.
- Nel formato JSON, includi sia la chiave attuale che 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 corrente.
- Monitora e verifica che i servizi siano ancora integri dopo l'utilizzo della nuova chiave. Attendi almeno un giorno dopo l'utilizzo della nuova chiave prima di procedere con il 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, ad esempio la risorsa personalizzata UserAuth, il client secret OIDC, le chiavi di crittografia, deve essere replicata in ogni cluster.
Per impostazione predefinita, il gateway in entrata bilancia il carico delle richieste di autenticazione a una qualsiasi delle istanze authservice
. Puoi utilizzare la regola di destinazione per configurare il gateway in entrata in modo che invii le richieste a authservice
nello stesso cluster e che esegua 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 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 le mappature 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 dall'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 configurate:
"attributes": {
"aud_copy": "foo.googleusercontent.com",
"decision": "success"
}
Se l'espressione CEL non riesce ad analizzare il valore di IDToken, ignorerà l'attestazione senza interrompere il flusso di autenticazione.
Upgrade dell'autenticazione utente
Installa di nuovo i pacchetti user-auth perché contengono il 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 di configurazione dell'autenticazione utente
La tabella seguente descrive ogni campo 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 del proxy HTTPS, se presente. |
authentication.oidc.oauthCredentialsSecret |
Riferimenti secret al secret di tipo Opaque di Kubernetes che contiene client_id e client_secret OAuth2 OIDC nel payload JSON. |
authentication.oidc.issuerURI |
L'URI da utilizzare come emittente nel token RCToken di output. |
authentication.oidc.proxy |
Server proxy per l'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, verrà utilizzato l'host dell'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 a un dominio di livello superiore. Ad esempio, per attivare l'SSO tra profile.example.com/ e admin.example.com/, questo valore può essere impostato su example.com. In questo modo, verrà stabilita una sessione di autenticazione utente su example.com che verrà condivisa tra tutti i sottodomini. Nota: se più domini vengono pubblicati dalla stessa mesh, example1.com e example2.com, la funzionalità non può essere utilizzata ed è consigliabile lasciarla vuota. |
authentication.oidc.redirectURIPath |
Il percorso dell'endpoint in cui authservice terminerà il flusso OAuth. Devi
registrare questo percorso URI più l'host come URI di reindirizzamento autorizzato nel
server di autorizzazione per authentication.oidc.clientID .Inoltre, questo URI deve essere pubblicato dallo stesso mesh di servizi e dall'ingresso in cui è abilitato authservice . |
authentication.oidc.scopes |
L'ambito OAuth da richiedere nella richiesta di autenticazione. Elenco separato da virgole di identificatori utilizzati per specificare quali privilegi di accesso vengono richiesti oltre all'ambito "openid", ad es. "groups,allatclaim". |
authentication.oidc.groupsClaim |
Se idtoken contiene un'attestazione di gruppo, utilizza questo campo per indicarne il nome. Se specificato, il servizio trasmetterà i dati in questa
attestazione nell'attestazione groups nell'RCToken di output. Questa rivendicazione deve contenere un elenco di stringhe separate da virgole, ad es. ["group1", "group2"]. |
authentication.oidc.attributeMapping |
Contiene una o più mappature delle rivendicazioni da idtoken seguite da espressioni CEL. Tutte le rivendicazioni
devono fare riferimento a assertion.X , assertion fa riferimento
all'IDToken originale, ad esempio aud_copy: assertion.aud |
authentication.outputJWTAudience |
Il pubblico dell'RCToken generato da authservice . I sidecar possono
convalidare l'RCToken in entrata rispetto a questo valore del segmento di pubblico. |
Risoluzione dei problemi
Accessibilità di rete all'IDP.
Possibile log:
error: TLS handshake failed.
.Verifica eseguendo
curl
dal container effimero collegato aistio-proxy
per chiamare l'URI dell'emittente IDP. Ad esempio, vedi Raccolta dei log di Cloud Service Mesh.Se non riesci a connetterti, controlla 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.
oerror: TLS handshake failed.
.Assicurati che
certificateAuthorityData
contenga il certificato CA radice corretto. Quando non è presente un proxy HTTPS che termina il traffico HTTPS, questo deve contenere il certificato CA radice per l'IdP. Se presente, deve contenere invece il proxy.Configurazione del percorso di reindirizzamento.
Possibile osservazione: ricezione della pagina di errore 404 durante il flusso di autenticazione OIDC.
L'autenticazione utente restituisce l'intestazione "Set-Cookie" senza utilizzare l'attributo path, che per impostazione predefinita il browser utilizza la directory dell'URL della richiesta come percorso del cookie (ambito del cookie correlato al percorso). Pertanto, ti consigliamo di non includere "/" nel percorso di reindirizzamento, a meno che non sia intenzionale.
Il sidecar non è in grado di recuperare jwksUri.
In alcuni scenari, una limitazione del sidecar potrebbe causare un errore nel recupero di jwksUri. Se lo spazio dei nomi non è presente utilizzando un carattere jolly (ad esempio,
./*
oistio-system/*
), questa operazione non funzionerà. Devi aggiungere manualmente il relativo spazio dei nomi nel sidecar di uscita.
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 di overlay aggiungendo
--custom_overlay user-auth-overlay.yaml
alla riga di comandoasmcli install
.Quante risorse dobbiamo eseguire il provisioning per
authservice
? E quante richieste al secondo può gestire?Per impostazione predefinita,
authservice
è configurato con 2 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 è proporzionale alla sua capacità di gestione delle richieste. Puoi anche configurare più repliche di authservice per aumentare la scalabilità orizzontale.