Anthos Service Mesh-Nutzerauthentifizierung konfigurieren

Die Anthos 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 Anthos Service Mesh verwendet, um eine Webanwendung zu hosten, auf die ihre Mitarbeiter über einen Webbrowser zugreifen können. Darüber hinaus muss die Organisation ihren vorhandenen Identitätsanbieter verwenden, um die Nutzeridentitäten zu verwalten. Die Nutzerauthentifizierung von Anthos Service Mesh erleichtert Nutzern die Authentifizierung über einen standardmäßigen webbasierten Anmelde- und Einwilligungsvorgang über OpenID Connect (OIDC). Wenn der Nutzer sich authentifiziert, erzwingt Anthos Service Mesh Istio-Autorisierungsrichtlinien und überträgt bei der erfolgreichen Autorisierung die Identität in einem sicheren Anmeldedatenformat an Arbeitslasten.

Funktionsweise

Die Nutzerauthentifizierung von Anthos 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 Integration in jeden Identitätsanbieter, der als OIDC-Autorisierungsserver fungieren kann. Wenn der Nutzer authentifiziert wird, sind die Hauptinformationen 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 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 Hauptinformationen abzurufen und eine detaillierte Zugriffssteuerung zu erzwingen.

Das folgende Diagramm zeigt den Standort von authservice im Mesh-Netzwerk und dessen Bezug zu den anderen Teilen des Mesh-Netzwerks. Dazu zählen der eingehende Traffic, Arbeitslasten und der Browser des Nutzers sowie ein vorhandener IdP.

Endnutzerauthentifizierung

Administratoren können authservice als Add-on für eine Anthos 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 Anthos 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 folgenden Schritte aus, um sicherzustellen, dass Sie die Voraussetzungen erfüllen.

Installation mithilfe des Overlays für die Nutzerauthentifizierung anpassen

Zum Installieren des Nutzerauthentifizierungsdienstes müssen Sie die ASM-Installation anpassen, um einen externen Autorisierungsanbieter auf Mesh-Ebene hinzuzufügen.

  1. Rufen Sie das Beispiel-Overlay zur Nutzerauthentifizierung ab und aktualisieren Sie es, wenn in Ihrem Mesh Anpassungen vorgenommen werden. Es wird empfohlen, diese Overlay-Datei in Ihrer Versionsverwaltung zu pflegen.

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

  2. Folgen Sie der Anleitung zum Installieren von ASM mit Overlay, um Anthos Service Mesh mit einem von Google bereitgestellten Skript mit dem Overlay zur Nutzerauthentifizierung zu installieren. Beispiel:

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

    Die kpt-Pakete für die Nutzerauthentifizierung erstellen eine AuthorizationPolicy, die auf den von pkg/ext-authz.yaml angegebenen externen Autorisierungsanbieter verweist.

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.
    • Setzen Sie Autorisierter Weiterleitungs-URI auf https://localhost:8443/_gcp_anthos_callback.

    Klicken Sie anschließend auf Speichern.

  3. Speichern Sie außerdem die OIDC-Clientkonfiguration, um sie später zu verwenden.

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

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.

  1. Rufen Sie das kpt-Paket ab:

    kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth@release-1.0 .
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. In einer Produktionsbereitstellung sollten keine selbst signierten Zertifikate verwendet werden.

  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 istio-system 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. Nachdem Sie die Schlüssel generiert haben, legen Sie die Schlüsseldaten im selben Format fest:

    cat ./samples/rctoken_signing_key.json
{
  "keys":[
     {
        "kty":"RSA",
        "kid":"rsa-signing-key",
        "K":"YOUR_KEY", # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735, # unix timestamp
     }
  ]
}

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

  2. Erstellen Sie das Kubernetes-Secret, das authservice in einem eigenen Dateisystem bereitstellt.

    Sie finden den Labelwert REVISION, indem Sie die Istiod-Bereitstellung prüfen.

    kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
kubectl create secret generic secret-key  \
    --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
    --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
    --namespace=asm-user-auth

Nutzerauthentifizierungsdienst bereitstellen

Mit den folgenden Befehlen werden der Nutzerauthentifizierungsdienst und die Bereitstellung im Namespace asm-user-auth erstellt.

  1. Legen Sie die oauth-Variablen fest. Die Client-ID und das Secret werden als Kubernetes-Secrets gespeichert. Daher verwenden wir Base64, um sie zu codieren.

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

  2. 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 enthält die folgenden Felder:

cat pkg/user_auth_config.yaml

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

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 werden nach Abschluss der vorherigen Installationsschritte erforderlich.

Nutzerauthentifizierung für Anwendungen aktivieren

In diesem Abschnitt wird gezeigt, wie Sie die Nutzerauthentifizierung aktivieren. Als Beispiel wird die Beispielanwendung "Online Boutique" verwendet.

Die Nutzerauthentifizierung für Anthos Service Mesh verwendet eine als CUSTOM typisierte Autorisierungsrichtlinie, um den OIDC-Ablauf auszulösen.

Beim Installationsvorgang wird auch ein Istio-Gateway erstellt, um HTTPS-Traffic mit dem oben erstellten TLS-Zertifikat userauth-tls-cert bereitzustellen. Hier ist die Konfiguration von pkg/gateway.yaml.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

  1. Aktualisieren Sie die Online Boutique-Anwendung so, dass sie dieses Gateway für die Bereitstellung von HTTPS-Traffic verwendet, und verwenden Sie die Portweiterleitung für den lokalen Zugriff auf die Anwendung:

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

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

  2. Prüfen Sie, ob die Beispielanwendung "Online Boutique" unter https://localhost:8443/ zugänglich ist.

Nutzerauthentifizierung prüfen

Bei den Online Boutique-Anwendungsdiensten müssen sich die Endnutzer nun über ihre Google-Konten anmelden.

  1. Prüfen Sie unter https://localhost:8443/, ob die OIDC-Anmeldeseite unter angezeigt wird.

  2. Klicken Sie nach der Anmeldung auf Weiter und prüfen Sie, ob Sie auf die Startseite von Online Boutique 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/rctoken-authz.yaml

  2. Die Datei rctoken-authz.yaml konfiguriert das Ingress-Gateway so, dass das von authservice ausgestellte RC-Token validiert und nur 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: RequestAuthentication
metadata:
 name: require-rc-token
 namespace: istio-system
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 jwtRules:
 - issuer: "authservice.asm-user-auth.svc.cluster.local"
   audiences:
   - "test_audience"
   jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
   fromHeaders:
   - name: X-ASM-RCTOKEN
   forwardOriginalToken: true
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: require-rc-token
 namespace: istio-system
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 action: ALLOW
 rules:
 - when:
   - key: request.auth.claims[iss]
     values:
     - authservice.asm-user-auth.svc.cluster.local
   - key: request.auth.claims[aud]
     values:
     - test_audience

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.

Achten Sie außerdem darauf, dass die in der CRD UserAuthConfig konfigurierten Parameter tokenEndpoint und authorizationEndpoint eine Route haben, die in VirtualService konfiguriert ist. In den vorherigen Installationsschritten wurde dies in asm-user-auth/userauth-oidc VirtualService festgelegt.

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

Anthos Service Mesh verwendet den symmetrischen Schlüssel zum Verschlüsseln von Sitzungsdaten, die in Browser-Cookies gespeichert sind. Um die Gültigkeit vorhandener Sitzungen sicherzustellen, 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 durchzufü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.

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-Zertifikat der Domain des OIDC-Autorisierungsservers.
authentication.oidc.clientSecret Tsecret-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.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 demselben Ingress bereitgestellt werden, für den "authservice" aktiviert ist.
authentication.oidc.scopes Der OAuth-Bereich, der in der Authentifizierungsanfrage angefordert werden soll.
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.
authentication.outputJWTAudience Die Zielgruppe des RCToken, das von „authservice“ generiert wurde. Die Sidecars können das eingehende RCToken mit diesem Zielgruppenwert validieren.

Multi-Cluster-Bereitstellung

Die Anthos 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.

Häufig gestellte Fragen

  1. Wie führe ich ein Upgrade von Anthos Service Mesh mit aktivierter Nutzerauthentifizierung durch?

    Folgen Sie dem Anthos Service Mesh-Upgradeprozess und geben Sie die Overlay-Datei user-auth.yaml in der Befehlszeile für install_asm an.

  2. Wie viele Ressourcen sollten wir für den authservice bereitstellen? Und 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, ungefähr 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.