Sie sehen die Dokumentation zum Service Mesh für Version 1.21.

Verfügbare Versionen

Cloud Service Mesh
1.22-Archiv
1.21-Archiv
1.20-Archiv
1.19-Archiv
1.18-Archiv

Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Service Mesh-Nutzerauthentifizierung konfigurieren

Die Cloud Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung für browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung auf 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 zum Hosten eines Webs verwendet Anwendung, auf die die Mitarbeiter über einen Webbrowser zugreifen können. Darüber hinaus muss die Organisation die Nutzeridentitäten mit ihrem vorhandenen Identitätsanbieter verwalten. Mit der Cloud Service Mesh-Nutzerauthentifizierung können Nutzer mit einem standardmäßigen webbasierten OIDC-Log-in (OpenID Connect) und der Einwilligung authentifizieren Ablauf. Wenn sich der Nutzer authentifiziert, erzwingt Cloud Service Mesh die Istio-Autorisierung und nach erfolgreicher Autorisierung wird die Identität in einem sicheren Anmeldedatenformat erstellen.

Funktionsweise

Durch die Nutzerauthentifizierung von Cloud Service Mesh wird die neue Komponente authservice eingeführt. 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.

Endnutzerauthentifizierung

Administratoren können authservice als Add-on über ein Cloud Service Mesh installieren Installation. Nach der Installation liest authservice die OIDC-Endpunktkonfiguration und andere zugehörige Einstellungen, die in der benutzerdefinierten Ressource UserAuth definiert sind. Der Administrator kann Cloud Service Mesh ExternalAuthorization APIs verwenden um auth_server als Filter für 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:

Wenn Sie das verwaltete Cloud Service Mesh in einem privaten Cluster verwenden, achten Sie darauf, dass die kann der Cluster ausgehenden Traffic an den IdP senden.

Wichtig :kpt ist ein Open-Source-Tool, mit dem Sie Kubernetes-Ressourcen validieren und anwenden. Du benötigst kpt v1.0 oder später ansehen.
Rufen Sie das kpt-Paket ab:
```
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 .
cd asm-user-auth/
```
Dieser Befehl ruft ein kpt-Paket mit den empfohlenen authservice-Konfiguration aus dem öffentliches Repository. Die Paket enthält Manifeste, um den Container authservice als Pod bereitzustellen asm-user-auth. Außerdem wird das Ingress-Gateway so konfiguriert, erfordern eine Autorisierung für alle Anfragen.

Externen Autorisierungsanbieter konfigurieren und ein Ingress-Gateway bereitstellen

Passen Sie das Cloud Service Mesh an, um den Nutzerauthentifizierungsdienst zu installieren um einen externen Autorisierungsanbieter hinzuzufügen. Erforderliche Schritte hängt davon ab, ob Sie das verwaltete oder clusterinterne Cloud Service Mesh verwenden.

Verwaltet

Mesh-Konfiguration in Istio aktualisieren ConfigMap zum Hinzufügen eines externen Autorisierungsanbieters hinzu. Im Folgenden denselben REVISION_LABEL wie den Bereitstellung von verwaltetem Cloud Service Mesh (z. B. asm-managed, asm-managed-rapid oder asm-managed-stable):
```
kubectl edit configmap istio-REVISION_LABEL -n istio-system
```

Fügen Sie den Erweiterungsanbieter unter dem Feld mesh hinzu:

mesh: |-
...
  extensionProviders:
  - name: "asm-userauth-grpc"
    envoyExtAuthzGrpc:
      service: "authservice.asm-user-auth.svc.cluster.local"
      port: "10003"

Erstellen Sie den Namespace asm-user-auth und fügen Sie ihm ein Label hinzu.

kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION_LABEL --overwrite

Ingress-Gateway installieren im Namespace asm-user-auth.
```
kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
```
Hinweis: DIR_PATH bezieht sich auf den Speicherort des anthos-service-mesh-packages-Repositorys auf Ihrem Computer. Wenn sich dieses Repository nicht auf Ihrem Computer befindet, klonen Sie es: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

Clusterintern

Beispiel abrufen Overlay für Nutzerauthentifizierung und aktualisieren Sie es, falls es Anpassungen in Ihrem Mesh gibt. 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. Sie verwenden ein von Google bereitgestelltes Skript, um Cloud Service Mesh mit dem Nutzer zu installieren. Authentifizierungs-Overlay. 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
```
Wichtig: Wenn Sie die Installation mit mehreren Overlays anpassen, müssen Sie Die Option --custom_overlay schließt alle Overlay-Dateien ein.

Die kpt-Pakete für die Nutzerauthentifizierung erstellen eine AuthorizationPolicy, die auf den von pkg/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 von kubectl 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
```
Hinweis: DIR_PATH bezieht sich auf den Speicherort des anthos-service-mesh-packages-Repositorys auf Ihrem Computer. Wenn sich dieses Repository nicht auf Ihrem Computer befindet, klonen Sie es: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

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.

Zu den Anmeldedaten
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.

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

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_AES_KEY",
        "useAfter": 1612813735
     }
  ]
}
```
Mit dem folgenden Befehl können Sie einen AES-Testschlüssel generieren:
```
openssl rand -base64 32
```

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_AES_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 Dienst zur Nutzerauthentifizierung und die Bereitstellung in den Namespace asm-user-auth.

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

Nachdem Sie die Installationsschritte abgeschlossen haben, sind die folgenden Aufgaben erforderlich.

Nutzerauthentifizierung für Anwendungen aktivieren

In diesem Abschnitt wird gezeigt, wie Sie die Nutzerauthentifizierung mithilfe der Methode httpbin-Beispielanwendung als Beispiel.

Die Cloud Service Mesh-Nutzerauthentifizierung verwendet eine CUSTOM von Ihnen eingegebene Autorisierungsrichtlinie zum Auslösen des OIDC-Vorgangs.

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 von istio-proxy für Bereitstellungen zu aktivieren.
```
kubectl label namespace default istio.io/rev=REVISION --overwrite
```

Stellen Sie httpbin im Namespace default 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

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.

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 der gespeicherten Sitzungsdaten in Browser-Cookies. 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 Bereitstellung in mehreren Clustern. Sie müssen die Nutzerauthentifizierung in jedem Cluster wie oben beschrieben bereitstellen. Die Konfiguration der Nutzerauthentifizierung wie als benutzerdefinierte UserAuth-Ressource, OIDC-Clientschlüssel, Verschlüsselungsschlüssel, in jedem Cluster repliziert werden.

Standardmäßig verteilt das Ingress-Gateway das Load-Balancing für die Authentifizierungsanfragen eine der authservice-Instanzen. Mit einer Zielregel können Sie das Ingress-Gateway an authservice im selben Cluster sendet, und ein Failover auf die 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

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 Container istio-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. 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.
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 ein Sidecar Einschränkung kann dazu führen, dass jwksUri nicht abgerufen werden kann. 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

Wie führe ich ein Upgrade von Cloud Service Mesh mit aktivierter Nutzerauthentifizierung durch?

Wenn Sie ein clusterinternes Cloud Service Mesh verwenden, folgen Sie der Cloud Service Mesh-Upgrade und geben Sie die Overlay-Datei an, indem Sie --custom_overlay user-auth-overlay.yaml in der Befehlszeile, um asmcli install.

Für das verwaltete Cloud Service Mesh wird automatisch ein Upgrade durchgeführt.
Wie viel CPU und Arbeitsspeicher soll ich für 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.