Cloud Service Mesh-Nutzerauthentifizierung konfigurieren
Die Cloud Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung für die browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung für Ihre bereitgestellten Arbeitslasten. Sie ermöglicht die Einbindung in vorhandene Identitätsanbieter (Identity Providers, IDP) für die Nutzerauthentifizierung und verwendet Istio APIs und Autorisierungsrichtlinien für die Zugriffsverwaltung. Dies ist eine nutzerfreundliche Alternative zur JWT-Authentifizierung (JSON Web Token) von Istio.
Ein typischer Anwendungsfall ist, wenn eine Organisation Cloud Service Mesh verwendet, um eine Webanwendung zu hosten, auf die ihre Mitarbeiter über einen Webbrowser zugreifen können. Darüber hinaus muss die Organisation die Nutzeridentitäten mit ihrem vorhandenen Identitätsanbieter verwalten. Die Nutzerauthentifizierung von Cloud Service Mesh erleichtert Nutzern die Authentifizierung durch einen standardmäßigen webbasierten Anmelde- und Einwilligungsvorgang über OpenID Connect (OIDC). Wenn der Nutzer sich authentifiziert, erzwingt Cloud Service Mesh Istio-Autorisierungsrichtlinien und überträgt bei der erfolgreichen Autorisierung die Identität in einem sicheren Anmeldedatenformat an Arbeitslasten.
Funktionsweise
Die Nutzerauthentifizierung von Cloud Service Mesh führt die neue Komponente authservice
ein.
Diese Komponente lässt sich in den Envoy-basierten Ingress als externen Autorisierungsdienst einbinden, der alle eingehenden Authentifizierungsanfragen abfängt. authservice
implementiert die Clientseite des OIDC-Protokolls und ermöglicht dem Nutzer den Zugriff auf Anwendungen über einen Browser, wobei Nutzer eine interaktive Authentifizierung und Einwilligung erteilen, um eine kurzlebige Sitzung einzurichten.
authservice
implementiert Branchenstandardprotokolle zur Einbindung in jeden Identitätsanbieter, der als OIDC-Autorisierungsserver dienen kann. Wenn der Nutzer authentifiziert wird, sind die Hauptkontoinformationen in einem RCToken
im JWT-Format gekapselt, das von authservice
signiert ist und an die Istio-Autorisierungsebene im eingehenden Traffic weitergeleitet wird. Dieses Modell bietet eine Perimeterzugriffssteuerung für den Traffic in das Mesh. Wenn der Nutzer berechtigt ist, auf eine Ressource zuzugreifen, wird dieses RCToken auch an die Mikrodienste weitergeleitet, um Hauptkontoinformationen abzurufen und eine detaillierte Zugriffssteuerung zu erzwingen.
Das folgende Diagramm zeigt den Standort von authservice
im Mesh-Netzwerk und dessen Bezug zu den anderen Elementen des Mesh-Netzwerks. Dazu zählen der eingehende Traffic, Arbeitslasten und der Browser des Nutzers sowie ein vorhandener IDP.
Administratoren können authservice
als Add-on für eine Cloud Service Mesh-Installation installieren. Nach der Installation liest authservice
die OIDC-Endpunktkonfiguration und andere zugehörige Einstellungen, die in der benutzerdefinierten Ressource UserAuth
definiert sind. Der Administrator kann die Cloud Service Mesh ExternalAuthorization
APIs verwenden, um auth_server
als Filter für den eingehenden Traffic zu konfigurieren.
Nutzerauthentifizierungsdienst installieren
In den folgenden Schritten wird erläutert, wie authservice
konfiguriert wird.
Vorbereitung
Führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um Folgendes zu tun:- Erforderliche Tools installieren
asmcli
herunterladen- Clusteradministratorberechtigungen erteilen
- Projekt und Cluster validieren
- Wenn Sie verwaltetes Cloud Service Mesh in einem privaten Cluster verwenden, achten Sie darauf, dass der Cluster ausgehenden Traffic an den IdP senden kann.
Führen Sie die folgenden Schritte aus, um sicherzustellen, dass Sie die Voraussetzungen erfüllen.
Authentifizierungs-Overlay für Installationsnutzer anpassen
Zum Installieren des Nutzerauthentifizierungsdienstes müssen Sie die Cloud Service Mesh-Installation anpassen, um einen externen Autorisierungsanbieter auf Mesh-Ebene hinzuzufügen. Die erforderlichen Schritte hängen davon ab, ob Sie verwaltetes Cloud Service Mesh oder Cloud Service Mesh im Cluster verwenden.
Verwaltet
Aktualisieren Sie die ConfigMap, um die Mesh-Konfiguration der Nutzerauthentifizierung aufzunehmen. Verwenden Sie im folgenden Befehl denselben
REVISION_LABEL
, den Sie bei der Bereitstellung des verwalteten Cloud Service Mesh verwendet haben (z. B.asm-managed
,asm-managed-rapid
oderasm-managed-stable
):kubectl edit configmap istio-REVISION_LABEL -n istio-system
Fügen Sie unter dem Feld
mesh
den folgenden Text in die MeshConfig ein:mesh: |- ... extensionProviders: - name: "asm-userauth-grpc" envoyExtAuthzGrpc: service: "authservice.asm-user-auth.svc.cluster.local" port: "10003"
Erstellen Sie einen
asm-user-auth
-Namespace und fügen Sie ihm ein Label hinzu.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
Informationen zum Label
REVISION
finden Sie unter Injektionslabels.Installieren Sie das Istio-Gateway im Namespace
asm-user-auth
.kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
Clusterintern
Rufen Sie das Beispiel-Overlay zur Nutzerauthentifizierung ab und aktualisieren Sie es, wenn in Ihrem Mesh-Netzwerk Anpassungen vorgenommen werden. Es wird empfohlen, diese Overlay-Datei in Ihre Versionsverwaltung einzubinden.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.3/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
Folgen Sie der Anleitung unter Cloud Service Mesh mit Overlay installieren, um ein von Google bereitgestelltes Skript zu verwenden, um Cloud Service Mesh mit dem Nutzerauthentifizierungs-Overlay zu installieren. Beispiel:
./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
Die
kpt
-Pakete für die Nutzerauthentifizierung erstellen eineAuthorizationPolicy
, die auf den vonpkg/ext-authz.yaml
angegebenen externen Autorisierungsanbieter verweist.Erstellen Sie einen
asm-user-auth
-Namespace und fügen Sie ihm ein Label hinzu.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
Sie finden den Labelwert für
REVISION
durch Prüfung vonkubectl get pod -n istio-system -L istio.io/rev
.Installieren Sie das Istio-Gateway im Namespace
asm-user-auth
.kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
Konfiguration des OIDC-Clients vorbereiten
Legen Sie die OIDC-Clientkonfiguration mit den folgenden Schritten fest. In dieser Anleitung wird Google als IDP verwendet. Sie können aber auch jeden IDP verwenden, der die OIDC-Authentifizierung unterstützt.
Rufen Sie in der Google Cloud Console API & Dienste > Anmeldedaten auf.
Wechseln Sie zu Anmeldedaten erstellen und wählen Sie OAuth-Client-ID aus. Legen Sie gegebenenfalls die Optionen für den OAuth-Zustimmungsbildschirm fest und konfigurieren Sie die folgenden Optionen:
- Setzen Sie den Anwendungstyp auf Webanwendung.
- Legen Sie für Autorisierter Weiterleitungs-URI den Wert
https://REDIRECT_HOST/REDIRECT_PATH
fest. Für den lokalen Host können Sie beispielsweisehttps://localhost:8443/_gcp_asm_authenticate
angeben.
Klicken Sie anschließend auf Speichern.
Speichern Sie außerdem die OIDC-Clientkonfiguration, um sie später zu verwenden.
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
kpt
-Pakete herunterladen
Führen Sie die folgenden Schritte aus, um die empfohlene authservice
-Konfiguration aus dem öffentlichen Repository zu installieren. Diese Befehle rufen den neuesten authservice
-Container ab und starten ihn als Pod im Namespace asm-user-auth
. Darüber hinaus wird der Ingress so konfiguriert, dass alle Anfragen abgefangen werden.
Rufen Sie das kpt-Paket ab:
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 .
cd asm-user-auth/
Weiterleitungs-URL und -Secret für Ingress-Gateway festlegen
OAuth2
erfordert eine Weiterleitungs-URL, die auf einem HTTPS-geschützten Endpunkt gehostet wird. Diese Befehle dienen als Beispiel und vereinfachen die Einrichtung, da ein selbst signiertes Zertifikat für das Istio-Ingress-Gateway generiert wird.
Generieren Sie ein selbstsigniertes Zertifikat:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -days 365 -nodes -subj '/CN=localhost'
Erstellen Sie ein Secret für das Ingress-Gateway, um HTTPS-Traffic zu hosten:
kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \ --cert=cert.pem
Verschlüsselungs- und Signaturschlüssel anwenden
authservice
benötigt zwei Schlüsselsätze, um ordnungsgemäß zu funktionieren. Der erste ist ein symmetrischer Schlüssel für die Ver- und Entschlüsselung. Dieser Schlüssel wird zum Verschlüsseln des Sitzungsstatus verwendet, bevor er als Cookie festgelegt wird.
Der zweite Schlüsselsatz ist ein öffentliches/privates Schlüsselpaar. Mit diesem Schlüssel werden die authentifizierten Nutzerinformationen im JWT-Format als RCToken signiert. Der öffentliche Schlüssel dieses Paars wird an einem vordefinierten Endpunkt veröffentlicht, mit dem die Sidecars das JWT prüfen können.
Das kpt
-Paket zur Nutzerauthentifizierung enthält zwei Beispielschlüssel für die schnelle Einrichtung.
Sie können diese Schlüssel jedoch auch mit Ihrem bevorzugten Schlüsselverwaltungssystem generieren.
Bereiten Sie den Sitzungsverschlüsselungsschlüssel im folgenden Format vor oder verwenden Sie das Beispiel aus dem pkg, das Sie mit
cat ./samples/cookie_encryption_key.json
anzeigen lassen können.{ "keys":[ { "kty":"oct", "kid":"key-0", "K":"YOUR_KEY", "useAfter": 1612813735 } ] }
Mit dem folgenden Befehl können Sie einen AES-Testschlüssel generieren:
openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key
Bereiten Sie den RCToken-Signaturschlüssel im folgenden Format vor oder verwenden Sie das Beispiel aus dem pkg, das Sie mit
cat ./samples/rctoken_signing_key.json
anzeigen lassen können.{ "keys":[ { "kty":"RSA", "kid":"rsa-signing-key", "K":"YOUR_KEY", # k contains a Base64 encoded PEM format RSA signing key. "useAfter": 1612813735 # unix timestamp } ] }
Mit dem folgenden Befehl können Sie einen privaten 256-Bit-RSA-Schlüssel generieren:
openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256
Erstellen Sie das Kubernetes-Secret, das
authservice
in einem eigenen Dateisystem bereitstellt.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
Nutzerauthentifizierungsdienst bereitstellen
Mit den folgenden Befehlen werden der Nutzerauthentifizierungsdienst und die Bereitstellung im Namespace asm-user-auth
erstellt.
Legen Sie die erforderlichen Werte für die Konfiguration der Nutzerauthentifizierung fest. Die Client-ID und das Secret werden als Kubernetes-Secrets gespeichert. Daher codieren wir sie mit Base64. Alle verfügbaren Setter finden Sie im öffentlichen Repository.
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}"
Wenden Sie das Paket kpt
an:
# 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
Der authservice
nutzt die UserAuthConfig
-CRD, um die Endnutzerauthentifizierung bereitzustellen. UserAuthConfig
ist in der Laufzeit konfigurierbar und Sie können sie aktualisieren, um das Verhalten von authservice
zu ändern und mit Endpunkten für jeden OIDC-Autorisierungsserver zu konfigurieren.
Sie können die Datei mit cat pkg/user_auth_config.yaml
anzeigen lassen. Sie enthält die folgenden Felder:
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}
Eine ausführliche Beschreibung der user_auth_config.yaml
-Felder finden Sie unter Konfigurationsdetails für die Nutzerauthentifizierung.
Aufgaben nach der Installation ausführen
Die folgenden Aufgaben müssen nach Abschluss der vorherigen Installationsschritte ausgeführt werden.
Nutzerauthentifizierung für Anwendungen aktivieren
In diesem Abschnitt wird gezeigt, wie Sie die Nutzerauthentifizierung aktivieren. Dazu wird als Beispiel httpbin
verwendet.
Die Nutzerauthentifizierung für Cloud Service Mesh verwendet eine als CUSTOM
typisierte Autorisierungsrichtlinie, um den OIDC-Ablauf auszulösen.
Nachdem Sie das Istio-Gateway installiert haben, konfigurieren Sie es so, dass HTTPS-Traffic mit dem oben erstellten TLS-Zertifikat userauth-tls-cert
bereitgestellt wird. Im Folgenden finden Sie die pkg/gateway.yaml
-Konfiguration, die Sie gerade installiert haben.
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
Fügen Sie dem
default
-Namespace ein Label hinzu, um die automatische Einfügung vonistio-proxy
für Bereitstellungen zu aktivieren.kubectl label namespace default istio.io/rev=REVISION --overwrite
Stellen Sie
httpbin
im Namespacedefault
bereit.kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default
Aktualisieren Sie
httpbin
so, dass dieses Gateway für die Bereitstellung von HTTPS-Traffic genutzt wird, und verwenden Sie die Portweiterleitung für den lokalen Zugriff auf die Anwendung:kubectl apply -f./samples/httpbin-route.yaml -n default kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
Das Ingress-Gateway an Port 8443 wird an
localhost
weitergeleitet, damit die Anwendung lokal zugänglich ist.Stellen Sie
samples/rctoken-authz.yaml
bereit, um RequestAuthentication und AuthorizationPolicy zu aktivieren, damit Sie das RCToken für die Anfragen prüfen können.kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth
Beispiel
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
Nutzerauthentifizierung prüfen
httpbin
stellt zwei Pfade bereit. /ip
ist öffentlich zugänglich und /headers
erfordert, dass sich der Endnutzer über seinen konfigurierten IDP anmeldet.
Prüfen Sie, ob Sie durch Aufrufen von
https://localhost:8443/ip
direkt auf/ip
zugreifen können.Prüfen Sie mit
https://localhost:8443/headers
, ob die OIDC-Anmeldeseite angezeigt wird.Klicken Sie nach der Anmeldung auf Weiter und prüfen Sie, ob Sie zur Seite
/headers
weitergeleitet werden.
Autorisierungsrichtlinien konfigurieren
Nachdem Sie die Konfiguration in den vorherigen Schritten abgeschlossen haben, wird jeder Nutzer über einen webbasierten Authentifizierungsvorgang weitergeleitet. Wenn der Vorgang abgeschlossen ist, generiert authservice
einen RCToken
im JWT-Format, mit dem die authentifizierten Nutzerinformationen übertragen werden.
Fügen Sie am Ingress Autorisierungsrichtlinien von Istio hinzu, damit für jeden authentifizierten Nutzer eine Autorisierungsprüfung durchgeführt wird:
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
Die Datei
httpbin-authz.yaml
konfiguriert das Ingress-Gateway so, dass das von authservice ausgestellte RC-Token validiert und nur dann autorisiert wird, wenn das JWT die gewünschten Felder wie Zielgruppen und Aussteller enthält.Sehen Sie sich die folgende Beispiel-Autorisierungsrichtlinie an:
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.
Umgebungsspezifische Einstellungen konfigurieren
In den vorherigen Schritten werden localhost
und ein selbst signiertes HTTPS-Zertifikat für eine schnelle Einrichtung verwendet. Verwenden Sie für eine reale Produktionsumgebung Ihre eigene Domain, z. B. example.com
.
Außerdem muss certificateAuthorityData
den erforderlichen Inhalt des Root-Zertifikats haben. Wenn der IDP beispielsweise die Root-Zertifikate des Systems akzeptiert, können Sie es leer lassen. Wenn die HTTPS-Verbindung ein HTTPS-Proxy beendet, sollte für diesen das Root-Zertifikat des Proxys festgelegt werden.
Schlüssel verwalten und rotieren
authservice
verwendet zwei Gruppen von Schlüsseln. Sie können jeden Schlüssel unabhängig rotieren. Bevor Sie die Schlüssel rotieren, sollten Sie jedoch wissen, wie die Rotation funktioniert.
Beide Schlüssel haben das JSON-Format. Das Feld useAfter
gibt den Zeitstempel an, seit der Schlüssel als zu verwenden betrachtet wird. Während einer Schlüsselrotation sollten Sie sowohl alte als auch neue Schlüssel in die JSON-Datei aufnehmen. Im folgenden Beispiel wird new-key
nur nach dem Zeitstempel 1712813735
verwendet.
{
"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 verwendet den symmetrischen Schlüssel zum Verschlüsseln von Sitzungsdaten, die in Browser-Cookies gespeichert sind. Um die Gültigkeit vorhandener Sitzungen zu gewährleisten, versucht authservice
, alle Schlüssel im Schlüsselsatz zu entschlüsseln. Bei der Rotation verwendet authservice
den neuen Schlüssel zum Verschlüsseln neuer Sitzungen und versucht weiterhin, die Entschlüsselung mit den alten Schlüsseln auszuführen.
Das öffentliche/private Schlüsselpaar wird zum Signieren von RCToken
verwendet. Der öffentliche Schlüssel wird von istiod
zur JWT-Überprüfung an die Sidecar-Dateien übertragen. Sidecar-Dateien müssen den neuen öffentlichen Schlüssel erhalten, bevor authservice
mit dem neuen privaten Schlüssel zum Signieren von RCToken
beginnt. Dazu beginnt authservice
mit der Veröffentlichung des öffentlichen Schlüssels unmittelbar nach dem Hinzufügen des Schlüssels, wartet jedoch einige Zeit, bevor dieser mit RCToken
signiert wird.
Zusammengefasst empfehlen wir bei der Schlüsselrotation Folgendes:
- Führen Sie Schlüsselrotationen in regelmäßigen Abständen oder nach Bedarf durch.
- Geben Sie im JSON-Format sowohl den aktuellen als auch den neuen Schlüssel an. Die neuen Schlüssel sollten einem Zeitstempel in der Zukunft zugeordnet werden. Wir empfehlen, einen Zeitstempel mindestens einige Stunden nach der aktuellen Uhrzeit anzugeben.
- Überwachen Sie, ob die Dienste weiterhin fehlerfrei sind, wenn der neue Schlüssel in Verwendung ist. Warten Sie nach der Verwendung des neuen Schlüssels mindestens einen Tag, bevor Sie mit dem nächsten Schritt fortfahren.
- Entfernen Sie die alten Schlüssel aus den JSON-Einträgen. Sie werden nicht mehr benötigt.
Multi-Cluster-Bereitstellung
Die Cloud Service Mesh-Nutzerauthentifizierung unterstützt die Multicluster-Bereitstellung. Sie müssen die Nutzerauthentifizierung in jedem Cluster wie oben beschrieben bereitstellen. Die Konfiguration der Nutzerauthentifizierung wie die benutzerdefinierte UserAuth-Ressource, der OIDC-Clientschlüssel und die Verschlüsselungsschlüssel müssen in jedem Cluster repliziert werden.
Standardmäßig leitet das Ingress-Gateway die Authentifizierungsanfragen an eine der authservice
-Instanzen weiter. Mit der Zielregel können Sie das Ingress-Gateway so konfigurieren, dass Anfragen an den authservice
im selben Cluster gesendet werden und ein Failover nur auf den authservice
anderer Cluster erfolgt.
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
Wie bei jeder anderen Konfiguration muss dies in jedem Cluster konfiguriert werden.
Zuordnung benutzerdefinierter Anforderungen
Konfigurieren Sie spec.authentication.oidc.attributeMapping
so, dass Zuordnungen vom IDToken des ursprünglichen Identitätsanbieters definiert werden, um eine benutzerdefinierte Anspruchszuordnung zu konfigurieren. Der Schlüssel ist der Anforderungsname im RCToken und der Wert ist ein CEL-Ausdruck zum Parsen der Anforderung aus IDToken. Verwenden Sie assertion
, um auf das IDToken zu verweisen.
Beispiel:
spec:
authentication:
oidc:
attributeMapping:
aud_copy: assertion.aud
decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'
Im RCToken enthält ein verschachtelter Anspruch attributes
die konfigurierten Anforderungen:
"attributes": {
"aud_copy": "foo.googleusercontent.com",
"decision": "success"
}
Wenn der CEL-Ausdruck den Wert aus IDToken nicht parsen kann, wird die Anforderung ignoriert, ohne dass der Authentifizierungsablauf fehlschlägt.
Nutzerauthentifizierungsupgrades
Installieren Sie die user-auth-Pakete noch einmal, da sie die aktualisierte Binärdatei für die neue user-auth-Version enthalten:
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 . cd asm-user-auth/
Speichern Sie die OIDC-Clientkonfiguration:
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
Stellen Sie den Nutzerauthentifizierungsdienst bereit, um ein Upgrade auf eine neue Version durchzuführen.
Details zur Konfiguration der Nutzerauthentifizierung
In der folgenden Tabelle werden die einzelnen Felder der CRD beschrieben:
Feldname | Beschreibung |
---|---|
authentication.oidc |
Dieser Abschnitt enthält die OIDC-Endpunktkonfiguration und die im OIDC-Ablauf verwendeten Parameter. |
authentication.oidc.certificateAuthorityData |
Dies ist das SSL-Root-Zertifikat der Domain des OIDC-Autorisierungsservers oder des HTTPS-Proxys, falls vorhanden. |
authentication.oidc.oauthCredentialsSecret |
Secret-Referenzen auf das Secret des Kubernetes-Opaque-Typs, das client_id und client_secret von OAuth2 OIDC in der JSON-Nutzlast enthält. |
authentication.oidc.issuerURI |
Der URI, der als Aussteller im Ausgabe-RCToken verwendet werden soll. |
authentication.oidc.proxy |
Proxyserver an den OIDC-IDP, falls zutreffend. Im Format http://user:password@10.10.10.10:8888. |
authentication.oidc.redirectURIHost |
Der Host, der für den OAuth-Beendigungs-URI verwendet werden soll. Wenn Sie dieses Feld leer lassen, wird der Host der Ziel-URL verwendet und der Weiterleitungs-URI wird dynamisch zusammengestellt. Dieser Wert kann verwendet werden, wenn eine Nutzerauthentifizierungs-SSO in einer übergeordneten Domain erwünscht ist. Wenn Sie beispielsweise SSO zwischen profile.example.com/ und admin.example.com/ aktivieren möchten, kann dieser Wert auf example.com festgelegt werden. Dadurch kann bei example.com eine Nutzerauthentifizierungssitzung eingerichtet werden, die von allen Subdomains gemeinsam genutzt wird. Hinweis: Wenn mehrere Domains vom selben Mesh-Netzwerk, example1.com und example2.com, bereitgestellt werden, kann das Feature nicht verwendet werden. Deshalb sollte es leer bleiben. |
authentication.oidc.redirectURIPath |
Der Endpunktpfad, an dem authservice den OAuth-Ablauf beendet. Sie sollten diesen URI-Pfad sowie den Host als autorisierten Weiterleitungs-URI im Autorisierungsserver für authentication.oidc.clientID registrieren.Außerdem sollte der URI vom selben Service Mesh und Ingress bereitgestellt werden, für den authservice aktiviert ist. |
authentication.oidc.scopes |
Der OAuth-Bereich, der in der Authentifizierungsanfrage angefordert werden soll. Durch Kommas getrennte Liste von Kennungen, die angeben, welche Zugriffsrechte zusätzlich zum openid-Bereich angefordert werden, z. B. „groups,allatclaim“. |
authentication.oidc.groupsClaim |
Wenn das idtoken eine Gruppenanforderung enthält, geben Sie den Namen in diesem Feld an. Wenn angegeben, leitet der Dienst die Daten in dieser Anforderung an die Anforderung groups im Ausgabe-RCToken weiter. Diese Anforderung sollte eine durch Kommas getrennte Liste von Strings enthalten, z. B. ["Gruppe1", "Gruppe2"]. |
authentication.oidc.attributeMapping |
Enthält eine oder mehrere Anforderungszuordnungen von idtoken , denen CEL-Ausdrücke folgen. Alle Anforderungen sollten von assertion.X referenziert werden. assertion wird auf das ursprüngliche IDToken verwiesen, z. B. aud_copy: assertion.aud . |
authentication.outputJWTAudience |
Die Zielgruppe des RCToken, das von authservice generiert wurde. Die Sidecars können das eingehende RCToken mit diesem Zielgruppenwert validieren. |
Fehlerbehebung
Netzwerkzugriff auf IDP.
Mögliches Log:
error: TLS handshake failed.
.Prüfen Sie durch Ausführen von
curl
vom Containeristio-proxy
zum URI des IDP-Ausstellers. Wenn keine Verbindung hergestellt werden kann, sollte der Nutzer die Firewallregeln oder andere Netzwerkkonfigurationen für den Cluster prüfen.Zertifikat von Stammzertifizierungsstelle (Stamm-CA).
Mögliches Log:
error: The server's TLS certificate did not match expectations.
odererror: TLS handshake failed.
.Achten Sie darauf, dass
certificateAuthorityData
das richtige Stamm-CA-Zertifikat enthält. Wenn kein HTTPS-Proxy vorhanden ist, der HTTPS-Traffic beendet, sollte es das Stamm-CA-Zertifikat für den IDP enthalten. Wenn es einen Proxy gibt, sollte dies stattdessen das Stamm-CA-Zertifikat des Proxys sein.Konfiguration des Weiterleitungspfads.
Mögliche Beobachtung: 404-Fehlerseite während des OIDC-Authentifizierungsablaufs eingeblendet.
Die Nutzerauthentifizierung gibt den „Set-Cookie“-Header ohne das Pfadattribut zurück. Das Attribut verwendet der Browser standardmäßig für das Verzeichnis der Anfrage-URL als Cookie-Pfad (Bereich des Cookies, das sich auf den Pfad bezieht). Daher sollten Sie „/“ nicht in den Weiterleitungspfad aufnehmen, sofern dies nicht notwendig ist.
Die Sidecar-Datei kann jwksUri nicht abrufen.
In einigen Szenarien kann eine Sidecar-Einschränkung dazu führen, dass jwksUri nicht abgerufen wird. Wenn der Namespace mit einem Platzhalter (z. B.
./*
oderistio-system/*
) nicht vorhanden ist, funktioniert dies nicht. Sie müssen den Namespace in der Sidecar-Datei für ausgehenden Traffic manuell hinzufügen.
Häufig gestellte Fragen
Wie führe ich ein Upgrade von Cloud Service Mesh mit aktivierter Nutzerauthentifizierung durch?
Folgen Sie dem Cloud Service Mesh-Upgradeprozess und geben Sie die Overlay-Datei durch Hinzufügen von
--custom_overlay user-auth-overlay.yaml
in der Befehlszeile zuasmcli install
an.Wie viele Ressourcen sollten wir für den
authservice
bereitstellen? Wie viele Anfragen pro Sekunde kann er verarbeiten?Standardmäßig ist
authservice
mit 2,0 vCPUs und 256 Mi Speicher konfiguriert. Unter einer solchen Konfiguration kannauthservice
500 Anfragen pro Sekunde verarbeiten. Für die Verarbeitung größerer Anfragen sollten Sie mehr CPU bereitstellen, etwa proportional zur Kapazität für die Verarbeitung von Anfragen. Sie können auch mehrere Replikate von authservice konfigurieren, um die horizontale Skalierbarkeit zu erhöhen.