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.

Endnutzerauthentifizierung

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

  • Rufen Sie das kpt-Paket ab:

    kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.1 .
cd asm-user-auth/

    Dieser Befehl ruft ein kpt-Paket mit den empfohlenen authservice-Konfiguration aus dem öffentliches Repository. Das Paket enthält Manifeste, um den authservice-Container als Pod im Namespace asm-user-auth bereitzustellen. Außerdem wird das Ingress-Gateway so konfiguriert, dass für alle Anfragen eine Autorisierung erforderlich ist.

Authentifizierungs-Overlay für Installationsnutzer anpassen

Sie müssen das Cloud Service Mesh anpassen, um den Nutzerauthentifizierungsdienst zu installieren 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

  1. 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 oder asm-managed-stable):

    kubectl edit configmap istio-REVISION_LABEL -n istio-system

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

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

  4. Installieren Sie das Istio-Gateway im Namespace asm-user-auth.

    kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

Clusterintern

  1. 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.1/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml

  2. 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 eine AuthorizationPolicy, die auf den von pkg/ext-authz.yaml angegebenen externen Autorisierungsanbieter verweist.

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

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

  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

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_AES_KEY",
        "useAfter": 1612813735
     }
  ]
}

    Mit dem folgenden Befehl können Sie einen AES-Testschlüssel generieren:

    openssl rand -base64 32

  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_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

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

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

  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 Bereitstellung in mehreren Clustern. 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.1 .
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:

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

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

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

  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.