Cloud Service Mesh-Nutzerauthentifizierung konfigurieren

Wenn Sie die TRAFFIC_DIRECTOR Steuerungsebene verwenden, wird diese Funktion nur über eine Zulassungsliste unterstützt. Wenden Sie sich an den Support, um Zugriff zu beantragen.

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 sich der Nutzer 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

• 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.

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.

1. Rufen Sie in der Google Cloud Console API & Dienste > Anmeldedaten auf.

   Zu den Anmeldedaten

2. 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 beispielsweise https://localhost:8443/_gcp_asm_authenticate angeben.

   Klicken Sie anschließend auf Speichern.

3. 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.

1. Generieren Sie ein selbstsigniertes Zertifikat:

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

2. 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.

1. 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
   

2. 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
   

3. 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

1. Fügen Sie dem default-Namespace ein Label hinzu, um die automatische Einfügung von istio-proxy für Bereitstellungen zu aktivieren.

   kubectl label namespace default istio.io/rev=REVISION --overwrite
   

2. Stellen Sie httpbin im Namespace default bereit.

   kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default
   

3. 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
   

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: httpbin
     namespace: default
   spec:
     gateways:
     - asm-user-auth/userauth
     hosts:
     - '*'
     http:
     - match:
       - uri:
           prefix: /ip
       - uri:
           prefix: /headers
       name: httpbin-routes
       route:
       - destination:
           host: httpbin.default.svc.cluster.local
           port:
             number: 8000
   

   Das Ingress-Gateway an Port 8443 wird an localhost weitergeleitet, damit die Anwendung lokal zugänglich ist.

4. 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.

1. Prüfen Sie, ob Sie durch Aufrufen von https://localhost:8443/ip direkt auf /ip zugreifen können.

2. Prüfen Sie mit https://localhost:8443/headers, ob die OIDC-Anmeldeseite angezeigt wird.

3. 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.

1. 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
   

2. 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:

1. Führen Sie Schlüsselrotationen in regelmäßigen Abständen oder nach Bedarf durch.
2. 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.
3. Ü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.
4. 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

1. 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/
   

2. 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
   

3. 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:

Fehlerbehebung

1. Netzwerkzugriff auf IDP.

   Mögliches Log: error: TLS handshake failed..

   Prüfen Sie durch Ausführen von curl aus dem sitzungsspezifischen Container, der mit istio-proxy verknüpft ist, um den URI des IDP-Ausstellers aufzurufen. Weitere Informationen finden Sie beispielsweise unter Cloud Service Mesh-Protokolle erfassen.

   Wenn Sie keine Verbindung herstellen können, prüfen Sie die Firewallregeln oder andere Netzwerkkonfigurationen für den Cluster.

2. Zertifikat von Stammzertifizierungsstelle (Stamm-CA).

   Mögliches Log: error: The server's TLS certificate did not match expectations. oder error: 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.

3. 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.

4. 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. ./* oder istio-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

1. 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 zu asmcli install an.

2. 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 kann authservice 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.