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 le applicazioni basate su browser l'autenticazione dell'utente finale e il controllo dell'accesso ai carichi di lavoro di cui si esegue il deployment. Consente di l'integrazione con provider di identità (IdP) esistenti per l'autenticazione degli utenti e utilizza le API e i criteri di autorizzazione di Istio per la gestione degli accessi. È una un'alternativa facile da usare all'autenticazione JWT (JSON Web Token) di Istio.
Un caso d'uso tipico è quando un'organizzazione utilizza Cloud Service Mesh per ospitare un un'applicazione web che consente alla forza lavoro di 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 la gestione Autenticazione tramite accesso e consenso OpenID Connect (OIDC) basato sul web standard flusso di lavoro. 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 il traffico in entrata basato su Envoy come un server
di autorizzazione che intercetta tutte le richieste in entrata
autenticazione. authservice
implementa il lato client del protocollo OIDC
e consente agli utenti di accedere alle applicazioni tramite un browser, nel quale gli utenti completano
l'autenticazione interattiva e il flusso di consenso per stabilire una sessione di breve durata.
authservice
implementa protocolli standard del settore per l'integrazione con qualsiasi
che può fungere da server di autorizzazione OIDC. Quando l'utente visualizza
autenticati, le informazioni dell'entità sono incapsulate in un oggetto RCToken
in JWT
firmato da authservice
che inoltra all'autorizzazione Istio
livello in entrata. Questo modello fornisce il controllo dell'accesso perimetrale per il traffico
all'interno della rete. Se l'utente è autorizzato ad accedere a una risorsa, questo RCToken è
sono inoltre inoltrati ai microservizi per ottenere le informazioni sull'entità e
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.
Gli amministratori possono installare authservice
come componente aggiuntivo su Cloud Service Mesh
dell'installazione. Una volta installato, authservice
legge l'endpoint OIDC
configurazione e altre impostazioni associate definite nella configurazione di UserAuth
risorsa. 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 seguenti spiegano come configurare authservice
.
Prerequisiti
Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster. a:- .
- Installa gli strumenti necessari
- Scarica
asmcli
- Concedi le autorizzazioni di amministratore del cluster
- Convalida il progetto e il cluster
- 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 dell'autenticazione utente per l'installazione
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 richiesti dipendono dal fatto che utilizzi Cloud Service Mesh gestito o nel 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
, 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
Abilita lo spazio dei nomi per l'inserimento. 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 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 sotto la colonna
NAME
è l'etichetta di revisione che corrisponde 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
Nel cluster
Ottieni l'esempio overlay autorizzazione utente e aggiornalo se ci sono personalizzazioni nella tua rete mesh. È una best practice consigliata per mantenere questo file di overlay nel codice sorgente controllo.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.3/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
Segui le istruzioni per installare Cloud Service Mesh con overlay. per utilizzare uno script fornito da Google per installare Cloud Service Mesh con l'utente di autenticazione, 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
kpt
di autenticazione utente creano unAuthorizationPolicy
per fare riferimento al provider di autorizzazione esterno specificatopkg/ext-authz.yaml
.Crea lo spazio dei nomi
asm-user-auth
.kubectl create namespace asm-user-auth
Abilita 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
Consigliamo di utilizzare l'inserimento predefinito, ma l'inserimento basato sulle revisioni è supportato: Segui queste istruzioni:
Usa questo 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"}'
Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente,
REVISION_LABEL
è il valore della 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
Prepara la configurazione del client OIDC
Imposta la configurazione del client OIDC seguendo questi passaggi. Questa guida utilizza Google in qualità di IdP, ma puoi utilizzare qualsiasi IdP che supporti l'autenticazione OIDC.
Nella console Google Cloud, vai ad API e Servizi > Credenziali.
Vai a Crea credenziali, quindi scegli ID client OAuth. Se necessario, Imposta le opzioni della schermata per il consenso OAuth, quindi configura quanto segue opzioni:
- Imposta Tipo di applicazione su Applicazione web.
- Imposta URI di reindirizzamento autorizzato su
https://REDIRECT_HOST/REDIRECT_PATH
. Ad esempio, per localhost puoi 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 kpt
pacchetti
Segui questi passaggi per installare la configurazione consigliata per authservice
dal
repository pubblico. Questi
recuperano l'ultimo container authservice
e lo avviano come pod in
lo 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
sono a scopo di esempio e semplificano la configurazione generando un
per il gateway Istio in entrata.
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
Per funzionare correttamente, authservice
ha bisogno di due set di chiavi. Il primo è il
chiave simmetrica per la crittografia e la decrittografia. 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 utente autenticate in formato JWT come RCToken. La chiave pubblica di questa coppia viene pubblicata su un endpoint predefinito che i file collaterali 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 formato seguente o utilizza l'esempio dal pacchetto, che puoi visualizzare in base a
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 dal pacchetto, che puoi visualizzare in base a
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 a 256 bit di prova 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 in-app.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 vengono archiviati come secret di Kubernetes, perciò viene utilizzato Base64 per codificarli. Visita 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 la CRD UserAuthConfig
per fornire all'utente finale
autenticazione. UserAuthConfig
è configurabile in fase di esecuzione e può
aggiornalo per modificare il comportamento di authservice
e configurarlo con gli 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}
Consulta
dettagli di configurazione dell'autenticazione utente
per descrizioni dettagliate dei campi user_auth_config.yaml
.
Eseguire attività post-installazione
Dopo aver completato l'installazione precedente, dovrai eseguire le seguenti attività passaggi.
Attivare l'autenticazione utente per le applicazioni
Questa sezione illustra come abilitare l'autenticazione utente utilizzando il metodo
httpbin
, ad 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
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 diistio-proxy
deployment di machine learning.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 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
Il gateway in entrata sulla porta 8443 verrà inoltrato a
localhost
per accessibile in locale.Esegui il deployment di
samples/rctoken-authz.yaml
per abilitare RequestAuthentication e AuthorizationPolicy per verificare 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
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.
Verifica di poter accedere direttamente a
/ip
visitando la paginahttps://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
.
Configura 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
genererà un RCToken
in formato JWT, che utilizza per
trasmettere le informazioni utente autenticate.
Aggiungi i criteri di autorizzazione Istio all'ingresso per garantire che viene eseguita una verifica dell'autorizzazione per ciascun utente autenticato:
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
Il file
httpbin-authz.yaml
configura il gateway in entrata per convalidare il Token RC emesso da authservice e autorizzato solo quando il JWT contiene il valore come segmenti di pubblico e emittenti.Vedi l'esempio di criterio di autorizzazione che segue:
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 impostazioni specifiche per l'ambiente
Nei passaggi precedenti viene usato localhost
e un certificato HTTPS autofirmato per velocizzare
configurazione. 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 radice del sistema, puoi
lascia il campo vuoto. Se un proxy HTTPS 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 chiave
in modo indipendente. 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 a partire dal giorno
quando la chiave verrà considerata utilizzata. 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 di decriptarli con tutte le chiavi nella chiave impostata. 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 chiave 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 un
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 la chiave corrente che quella nuova. Le nuove chiavi devono essere associate a un timestamp 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.
Distribuzione multi-cluster
L'autenticazione utente di Cloud Service Mesh supporta il deployment di più cluster. Devi eseguire il deployment l'autenticazione utente in ogni cluster come descritto sopra. La configurazione dell'autenticazione utente, risorsa personalizzata UserAuth, client secret OIDC, chiavi di crittografia, devono essere replicati 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
gateway in entrata per inviare richieste a authservice
nello stesso cluster e
eseguire il failover solo sugli altri cluster authservice
.
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.
Mappatura delle attestazioni personalizzate
Per configurare la mappatura delle attestazioni personalizzate, configura spec.authentication.oidc.attributeMapping
per definire qualsiasi mapping dall'IDToken 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"'
In 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à la richiesta senza interrompere il flusso di autenticazione.
Upgrade dell'autenticazione utente
Installa di nuovo i pacchetti di autenticazione utente poiché contiene 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
Eseguire il deployment del servizio di autenticazione utente di eseguire l'upgrade a una nuova versione.
Dettagli di 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 secret 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.proxy |
Server proxy all'IdP OIDC, se applicabile. Con 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 si desidera una sessione SSO di autenticazione utente a un livello superiore a livello di dominio. 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 dallo stesso mesh vengono gestiti più domini, example1.com ed example2.com, la funzione non può essere utilizzata ed è è consigliabile lasciare vuoto il campo. |
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, l'URI deve essere fornito dallo stesso mesh di servizi e in entrata in cui authservice è abilitato. |
authentication.oidc.scopes |
L'ambito OAuth che deve essere richiesto nell'autenticazione richiesta. 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 dichiarazione deve contenere un
elenco di stringhe separate da virgole, ad es. ["gruppo1", "gruppo2"]. |
authentication.oidc.attributeMapping |
Contiene una o più mappature delle attestazioni da idtoken espressioni CEL seguite. Tutte le rivendicazioni
deve fare riferimento con assertion.X , viene fatto riferimento a assertion
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.
Log possibile:
error: TLS handshake failed.
.Verifica eseguendo
curl
dal container temporaneo collegato aistio-proxy
per chiamare URI dell'emittente IdP. Ad esempio, vedi Raccolta di Cloud Service Mesh log.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.
oerror: TLS handshake failed.
.Assicurati che
certificateAuthorityData
contenga il certificato CA principale corretto. In assenza di un proxy HTTPS che termina il traffico HTTPS, questo dovrebbe contenere il percorso radice Certificato CA per l'IdP. Se ce n'è uno, dovrebbe contenere invece quello del proxy.Configurazione del percorso di reindirizzamento.
Possibile osservazione: ricevi la pagina di errore 404 durante il flusso di autenticazione OIDC.
L'autenticazione utente restituisce il comando "Imposta cookie" senza utilizzare l'attributo path, che per impostazione predefinita utilizza la directory dell'URL della richiesta come percorso del cookie (ambito del cookie correlato al percorso). Quindi consigliamo di non includi "/" nel percorso di reindirizzamento, a meno che non sia intenzionale.
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,
./*
oistio-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 le Upgrade di Cloud Service Mesh e specificare il file dell'overlay aggiungendo
--custom_overlay user-auth-overlay.yaml
sulla riga di comando perasmcli 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 e configurare più repliche di authservice per aumentare e scalabilità orizzontale.