Mit OpenID Connect (OIDC) authentifizieren

Auf dieser Seite wird gezeigt, wie Sie mit einem OpenID-Anbieter die Authentifizierung für GKE On-Prem-Nutzercluster konfigurieren. Informationen zur Verwendung von OIDC mit ADFS finden Sie unter Mit OIDC und ADFS authentifizieren.

Eine Übersicht über den Authentifizierungsvorgang in GKE On-Prem finden Sie unter Authentifizierung.

Übersicht

GKE On-Prem unterstützt OpenID Connect (OIDC) als Authentifizierungsmechanismus für die Interaktion mit dem Kubernetes API-Server eines Nutzerclusters. GKE On-Prem liefert das Kubectl-Plug-in für OIDC, ein kubectl-Plug-in, mit dem die Authentifizierung für Clusternutzer automatisch aktiviert wird.

In dieser Übung konfigurieren Sie eine Beziehung zwischen Ihrem OpenID-Anbieter und kubectl.

Hinweis

In diesem Thema wird davon ausgegangen, dass Sie mit OAuth 2.0 und OpenID Connect vertraut sind. In diesem Thema wird davon ausgegangen, dass Sie mit OpenID-Bereichen und Anforderungen vertraut sind.

Identitätsanbieter auswählen

Unabhängig von der gewählten Option können Sie das in dieser Anleitung beschriebene Kubectl-Plug-in für OIDC verwenden, um die Konfiguration der Authentifizierung und den Authentifizierungsprozess selbst zu beschleunigen. In diesem Thema wird erläutert, wie Sie einen anderen OpenID-Anbieter als ADFS verwenden.

Kubectl-Plug-in für OIDC herunterladen

Laden Sie das Plug-in herunter und legen Sie Zugriffsberechtigungen fest:

Linux

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/linux_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Windows

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/windows_amd64/kubectl-oidc .

macOS

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/darwin_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Plug-in installieren

Installieren Sie das Plug-in durch Verschieben der ausführbaren Datei an einen beliebigen Speicherort unter Ihrem PATH. Die ausführbare Datei muss den Namen kubectl-oidc haben. Weitere Informationen finden Sie unter kubectl-Plug-ins installieren.

Weiterleitungs-URI erstellen

Beim Aufbau einer Beziehung zu Ihrem OpenID-Anbieter müssen Sie einen Weiterleitungs-URI angeben, mit dem der Anbieter ID-Tokens zurückgeben kann. Die Tokens gehen an das Kubectl-Plug-in für OIDC, das auf dem lokalen Computer jedes Mitarbeiters ausgeführt wird und einen Port Ihrer Wahl überwacht. Wählen Sie eine Portnummer größer als 1024, die für diesen Zweck geeignet ist. Dann lautet der Weiterleitungs-URI:

http://localhost:[PORT]/callback

Dabei ist [PORT] Ihre Portnummer.

Kubectl-Plug-in für OIDC bei Ihrem OpenID-Anbieter registrieren

Bevor Sie das Kubectl-Plug-in für OIDC mit Ihrem OpenID-Anbieter verwenden können, müssen Sie das Plug-in beim Anbieter registrieren. Die Registrierung umfasst folgende Schritte:

  • Informieren Sie sich über den URI des Dienstleisters. Hier sendet das Plug-in Authentifizierungsanfragen.

  • Teilen Sie dem Anbieter Ihren Weiterleitungs-URI mit.

  • Legen Sie eine Client-ID fest. Dies ist die ID, mit der der Anbieter das Plug-in identifiziert.

  • Richten Sie einen Clientschlüssel ein. Das Plug-in verwendet dieses Secret für die Authentifizierung beim OpenID-Anbieter.

  • Legen Sie einen benutzerdefinierten Bereich fest, mit dem das Plug-in die Sicherheitsgruppen des Nutzers anfordern kann.

  • Legen Sie einen benutzerdefinierten Anforderungsnamen fest, mit dem der Anbieter die Sicherheitsgruppen des Nutzers zurückgibt.

Die jeweilige Vorgehensweise hängt von Ihrem OpenID-Anbieter ab. Informationen zum Ausführen der Registrierungsschritte mit ADFS finden Sie unter Mit OIDC und ADFS authentifizieren.

Die oidc-Spezifikation in die GKE On-Prem-Konfigurationsdatei einsetzen

Während der Installation generieren Sie mithilfe von gkectl create-config eine GKE On-Prem-Konfigurationsdatei. Die Konfiguration enthält die folgende oidc-Spezifikation. Sie befüllen "oidc" mit Werten, die für Ihren Anbieter spezifisch sind:

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl: Die URL Ihres OpenID-Anbieters, beispielsweise https://example.com/adfs. Clientanwendungen wie das Kubectl-Plug-in für OIDC senden Autorisierungsanfragen an diese URL. Der Kubernetes API-Server verwendet diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens festzustellen. Es muss HTTPS verwendet werden. Das ist ein Pflichtfeld.
  • kubectlredirecturl: localhost-Weiterleitungs-URL für das Kubectl-Plug-in für OIDC. Sie müssen die Weiterleitungs-URL bei Ihrem OpenID-Provider für die Verwendung durch die diesem Cluster zugewiesene Client-ID registrieren. Das ist ein Pflichtfeld.
  • clientid: ID für die Clientanwendung, z. B. das Kubectl-Plug-in für OIDC, die Authentifizierungsanfragen an den OpenID-Anbieter sendet. Das ist ein Pflichtfeld.
  • clientsecret: Secret für die Client-Anwendung. Das ist ein Pflichtfeld.
  • usehttpproxy: Wählen Sie aus, ob ein Reverse-Proxy im Cluster bereitgestellt werden soll, um Connect-Agent Zugriff auf den lokalen OIDC-Anbieter zur Authentifizierung von Nutzern zu gewähren. Der Wert muss ein String sein: "true" oder "false". Das ist ein Pflichtfeld.
  • username: JWT-Anspruch zur Verwendung als Nutzername. Der Standardwert ist sub. Dies ist eine eindeutige ID des Endnutzers. Sie können je nach OIDC-Anbieter andere Ansprüche wie email oder name auswählen. Allerdings wird anderen Ansprüchen als email die Aussteller-URL vorangestellt, um Namenskonflikte mit anderen Plug-ins zu vermeiden.
  • usernameprefix: Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn dieses Flag nicht angegeben wird und username ein anderer Wert als "email" ist, wird standardmäßig das Präfix issueruri# verwendet. Mit dem Wert - können Sie das gesamte Präfix deaktivieren.
  • group: JWT-Anspruch, der als Gruppe des Nutzers verwendet werden soll. Wenn der Anspruch vorhanden ist, muss dies ein Array von Strings sein.
  • groupprefix: Präfix, das Gruppenansprüchen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Es sind beispielsweise die Gruppe foobar und das Präfix gid- gid-foobar gegeben.
  • scopes: Zusätzliche Bereiche, die als durch Kommentare getrennte Liste an den OpenID-Anbieter gesendet werden.
  • extraparams: Zusätzliche Schlüssel/Wert-Parameter, die an den OpenID-Anbieter gesendet werden.
  • capath: Pfad zum Zertifikat der Zertifizierungsstelle, die das Webzertifikat Ihres Identitätsanbieters signiert hat.

    GKE On-Prem-Cluster verwenden TLS, um die Kommunikation zwischen ihren Komponenten zu sichern. Damit Kubernetes bei der Installation und beim Knoten-Bootstrapping automatisch Clientzertifikate erzeugen kann, muss GKE On-Prem mit einer Zertifizierungsstelle installiert werden.

    Standardmäßig erstellt GKE On-Prem während der Installation eine neue Zertifizierungsstelle, die TLS-Zertifikate generiert. Die Zertifizierungsstelle und die generierten Zertifikate werden lokal im Admin-Cluster gespeichert.

Beispiel: Gruppe authentifizieren und autorisieren

Viele Anbieter codieren Eigenschaften zur Identifizierung von Nutzern wie E-Mail-Adressen und Nutzer-IDs in einem Token. Diese Attribute bringen jedoch implizite Risiken für Authentifizierungsrichtlinien mit sich:

  • Nutzer-IDs können das Lesen und Prüfen von Richtlinien erschweren.
  • E-Mail-Adressen können sowohl ein Verfügbarkeitsrisiko (wenn ein Nutzer seine primäre E-Mail-Adresse ändert) als auch ein Sicherheitsrisiko (wenn eine E-Mail neu zugewiesen werden kann) bewirken.

Deshalb empfiehlt es sich, Gruppenrichtlinien zu verwenden, da die GID sowohl nichtflüchtig als auch einfacher zu überwachen sein kann.

Angenommen, Ihr Anbieter erstellt OpenID-Tokens, die die folgenden Felder enthalten:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList: ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}
Bei diesem Tokenformat würde dann die oidc-Spezifikation Ihrer Konfigurationsdatei so aussehen: 
issueruri: 'https://server.example.com'
username: 'sub'
usernameprefix: 'uid-'
group: 'groupList'
groupprefix: 'gid-'
...

Nachdem Sie den Nutzercluster erstellt haben, können Sie den authentifizierten Nutzern mithilfe der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) einen autorisierten Zugriff gewähren. Sie können beispielsweise eine ClusterRole erstellen, die ihren Nutzern Lesezugriff auf die Secrets des Clusters gewährt, und eine ClusterRoleBinding-Ressource erstellen, um die Rolle an die authentifizierte Gruppe zu binden:

ClusterRole

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: secret-reader
  rules:
  - apiGroups: [""]
    # The resource type for which access is granted
    resources: ["secrets"]
    # The permissions granted by the ClusterRole
    verbs: ["get", "watch", "list"]

ClusterRoleBinding

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: read-secrets-admins
  subjects:
    # Allows anyone in the "us-east1-cluster-admins" group to
    # read Secrets in any namespace within this cluster.
  - kind: Group
    name: gid-us-east1-cluster-admins # Name is case sensitive
    apiGroup: rbac.authorization.k8s.io
    # Allows this specific user to read Secrets in any
    # namespace within this cluster
  - kind: User
    name: uid-u98523-4509823
    apiGroup: rbac.authorization.k8s.io
  roleRef:
    kind: ClusterRole
    name: secret-reader
    apiGroup: rbac.authorization.k8s.io

Serverzertifikat der Zertifizierungsstelle erstellen

Die kubeconfig-Datei Ihres Nutzerclusters speichert die CA-Daten des Hosts im Feld certificate-authority-data. Sie müssen diesen Wert decodieren und in einer lokalen Datei wie server-ca-cert speichern:

cat [USER_CLUSTER_KUBECONFIG]  | grep certificate-authority-data | awk '{ print $2}' | base64 --decode > server-ca-cert

Die Konfigurationsdatei für die Clientauthentifizierung generieren

Nachdem Sie den Nutzercluster für OpenID konfiguriert und erstellt haben, kann sich ein Nutzer im Cluster anmelden, indem er eine Konfigurationsdatei für die Clientauthentifizierung an kubectl oidc login übergibt. Sie generieren eine Konfigurationsdatei für die Clientauthentifizierung, indem Sie folgenden Befehl eingeben:

Linux

kubectl oidc client-config
--issuer-uri [ISSUER_URI] \
--redirect-uri [REDIRECT_URI] \
--client-id [CLIENT_ID] \
--client-secret [CLIENT_SECRET] \
--scopes "[CUSTOM_SCOPES]" \
--cluster-name [USER_CLUSTER_NAME] \
--server [CLUSTER_URL] \
--server-ca-file server-ca-cert \
--issuer-ca-file [CA_CERT] \
--extra-params [KEY]=[VALUE]
> client-config.yaml
  • [ISSUER_URI] ist der URI des Ausstellers.
  • [REDIRECT_URI] ist Ihr Weiterleitungs-URI.
  • [CLIENT_ID] ist die Client-ID für die Anwendung "kubectl".
  • [CLIENT_SECRET] ist der Clientschlüssel, der für Sie generiert wurde.
  • [USER_CLUSTER_NAME] ist der Name Ihres Nutzerclusters.
  • [CLUSTER_URL] ist die URL des Kubernetes API-Servers des Nutzerclusters.
  • --server-ca-file akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.
  • [CA_CERT] ist der Pfad zur öffentlichen CA-Datei des Ausstellers.
  • [CUSTOM_SCOPES] ist die durch Kommas getrennte Liste Ihrer benutzerdefinierten Bereiche für Sicherheitsgruppen.
  • --extra-param sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.

PowerShell

kubectl oidc client-config
--issuer-uri [ISSUER_URI] `
--redirect-uri [REDIRECT_URI] `
--client-id [CLIENT_ID] `
--client-secret [CLIENT_SECRET] `
--scopes "[CUSTOM_SCOPES]" `
--cluster-name [USER_CLUSTER_NAME] `
--server [CLUSTER_URL] `
--server-ca-file server-ca-cert `
--issuer-ca-file [CA_CERT] `
--extra-params [KEY]=[VALUE]
> client-config.yaml
  • [ISSUER_URI] ist der URI des Ausstellers.
  • [REDIRECT_URI] ist Ihr Weiterleitungs-URI.
  • [CLIENT_ID] ist die Client-ID für die Anwendung "kubectl".
  • [CLIENT_SECRET] ist der Clientschlüssel, der für Sie generiert wurde.
  • [USER_CLUSTER_NAME] ist der Name Ihres Nutzerclusters.
  • [CLUSTER_URL] ist die URL des Kubernetes API-Servers des Nutzerclusters.
  • --server-ca-file akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.
  • [CA_CERT] ist der Pfad zur öffentlichen CA-Datei des Ausstellers.
  • [CUSTOM_SCOPES] ist die durch Kommas getrennte Liste Ihrer benutzerdefinierten Bereiche für Sicherheitsgruppen.
  • --extra-param sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.

Mit diesem Befehl wird eine Client-Authentifizierungsdatei namens client-config.yaml erstellt. Bearbeiten Sie diese Datei nicht manuell. Jeder Mitarbeiter, der sich beim Nutzercluster authentifizieren muss, sollte client-config.yaml erhalten.

TLS-Zertifikate

GKE On-Prem-Nutzercluster verwenden TLS, um die gesamte Kommunikation zwischen Clusterkomponenten zu sichern. Damit Kubernetes bei der Installation und beim Knoten-Bootstrapping automatisch Clientzertifikate erzeugen kann, muss GKE On-Prem mit einer Zertifizierungsstelle installiert werden.

Standardmäßig erstellt GKE On-Prem während der Installation eine neue Zertifizierungsstelle, die TLS-Zertifikate generiert. Die Zertifizierungsstelle und die generierten Zertifikate werden lokal im Admin-Cluster gespeichert.

Mit dem Kubectl-Plug-in für OIDC einen Nutzercluster authentifizieren

Führen Sie die folgenden Schritte von Ihrem lokalen Computer oder Ihrer VM aus, um sich mithilfe der Clientauthentifizierungsdatei bei einem Nutzercluster zu authentifizieren:

  1. Initialisieren Sie das Plug-in mit der Datei client-config.yaml:

    kubectl oidc login --clientconfig-file=client-config.yaml --user [NAME] \
--kubeconfig [KUBECONFIG_OUTPUT_PATH]

    Dabei gilt:

    • [NAME] ist der von Ihnen gewählte Nutzername.
    • [KUBECONFIG_OUTPUT_PATH] der Ausgabespeicherort für die kubeconfig-Datei, in der die Anmeldedaten gespeichert sind.

    kubectl oidc login startet einen Browser, in dem der Nutzer oder Mitarbeiter seine Anmeldedaten eingeben kann.

    Die bereitgestellte kubeconfig-Datei enthält jetzt ein ID-Token, das von kubectl zur Authentifizierung beim Kubernetes API-Server auf dem Nutzercluster verwendet werden kann.

    ausführen.

  2. Sie sollten sich jetzt authentifizieren. Geben Sie einen kubectl-Befehl ein, um festzustellen, ob Sie sich erfolgreich authentifiziert haben. Beispiel:

    kubectl get nodes --kubeconfig [KUBECONFIG_OUTPUT_PATH]
Weiter
Mit OIDC und ADFS authentifizieren