Mit OIDC und ADFS authentifizieren

Auf dieser Seite wird gezeigt, wie Sie mit OpenID Connect (OIDC) und Active Directory Federated Services (ADFS) die Authentifizierung für GKE On-Prem-Nutzercluster konfigurieren.

Eine Übersicht über den Authentifizierungsablauf 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 verwenden Sie eine Reihe von ADFS-Verwaltungsassistenten, um eine Beziehung zwischen dem kubectl-Befehlszeilentool, Ihrem ADFS-Server und Ihrer AD-Mitarbeiterdatenbank zu konfigurieren.

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.

Dieses Thema gilt für Unternehmen mit folgender Infrastruktur:

  • Das Unternehmen verwendet Active Directory (AD) für seine Mitarbeiterdatenbank.
  • Das Unternehmen betreibt einen Active Directory Federation Services-Server (ADFS).
  • Der ADFS-Server fungiert als OpenID-Anbieter.

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

Sie müssen einen Weiterleitungs-URI angeben, mit dem der OpenID-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.

ADFS konfigurieren

In den folgenden Abschnitten wird erläutert, wie ADFS für GKE On-Prem konfiguriert wird.

Weiterleitungs-URI festlegen

  1. Öffnen Sie das ADFS-Verwaltungsfenster.

  2. Wählen Sie Anwendungsgruppen, Aktionen und Anwendungsgruppe hinzufügen aus.

  3. Wählen Sie Server Application aus. Geben Sie einen Namen und eine Beschreibung ein. Klicken Sie auf Weiter.

  4. Geben Sie den Weiterleitungs-URI ein. Sie erhalten eine Client-ID. So identifiziert der OpenID-Anbieter die Anwendung kubectl. Speichern Sie die Client-ID für eine spätere Verwendung.

  5. Wählen Sie Generate a shared secret aus. Die kubectl-Anwendung verwendet dieses Secret zur Authentifizierung beim OpenID-Anbieter. Speichern Sie das Secret für eine spätere Verwendung.

Sicherheitsgruppen konfigurieren (optional)

  1. Wählen Sie in der ADFS-Verwaltung Vertrauensstellungen der vertrauenden Seite und dann Vertrauensstellung der vertrauenden Seite hinzufügen aus.

  2. Wählen Sie Ansprüche unterstützend aus und klicken Sie auf Starten.

  3. Wählen Sie Enter data about relying party manually aus.

  4. Geben Sie einen Anzeigenamen ein.

  5. Überspringen Sie die beiden nächsten Schritte.

  6. Geben Sie eine Vertrauensstellungs-ID für die vertrauende Seite ein. Vorschlag: token-groups-claim.

  7. Wählen Sie für Access control policy die Option Permit everyone aus. Das bedeutet, dass alle Mitarbeiter ihre Sicherheitsgruppeninformationen mit kubectl oidc teilen.

  8. Klicken Sie auf Finish (Beenden).

LDAP-Attribute zu Anspruchsnamen zuordnen

  1. Wählen Sie in der ADFS-Verwaltung Vertrauensstellungen der vertrauenden Seite und dann Anspruchsausstellungsrichtlinie bearbeiten aus.

  2. Wählen Sie LDAP-Attribute als Ansprüche senden aus und klicken Sie auf Weiter.

  3. Geben Sie für Claim rule name den Wert groups ein.

  4. Wählen Sie für Attributspeicher die Option Active Directory aus.

  5. Wählen Sie in der Tabelle für LDAP-Attribut die Option Tokengruppen – Qualifizierte Namen aus. Wählen Sie unter Typ des ausgehenden Anspruchs die Option Gruppen aus.

  6. Klicken Sie auf Beenden und dann auf Übernehmen.

kubectl mit ADFS registrieren

Öffnen Sie im Administratormodus ein PowerShell-Fenster und geben Sie folgenden Befehl ein:

Grant-AdfsApplicationPermission `
    -ClientRoleIdentifier "[CLIENT_ID]" `
    -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
    -ScopeName "allatclaims", "openid"

Dabei gilt:

  • [CLIENT_ID] ist die kubectl-Client-ID, die Sie zuvor abgerufen haben.

  • [SERVER_ROLE_IDENTIFIER] ist die Anforderungs-ID, die Sie zuvor eingegeben haben. Denken Sie daran, dass als ID token-groups-claim vorgeschlagen wurde.

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:

PowerShell

kubectl oidc client-config `
--issuer-uri [ISSUER_URI] `
--redirect-uri [REDIRECT_URI] `
--client-id [CLIENT_ID] `
--client-secret [CLIENT_SECRET] `
--scopes "allatclaims" `
--cluster-name [USER_CLUSTER_NAME] `
--server [CLUSTER_URL] `
--server-ca-file server-ca-cert `
--issuer-ca-file [ADFS_CA_CERT] `
--extra-params "resource=token-groups-claim"
> 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 Ihres Clusters.
  • --server-ca-file akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.
  • [ADFS_CA_CERT] ist der Pfad zur öffentlichen Zertifikatsdatei für die ADFS-CA.
  • --extra-param sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.

Linux

kubectl oidc client-config \
--issuer-uri [ISSUER_URI] \
--redirect-uri [REDIRECT_URI] \
--client-id [CLIENT_ID] \
--client-secret [CLIENT_SECRET] \
--scopes "allatclaims" \
--cluster-name [USER_CLUSTER_NAME] \
--server [CLUSTER_URL] \
--server-ca-file server-ca-cert \
--issuer-ca-file [ADFS_CA_CERT] \
--extra-params "resource=token-groups-claim"
> 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 Ihres Clusters.
  • --server-ca-file akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.
  • [ADFS_CA_CERT] ist der Pfad zur öffentlichen Zertifikatsdatei für die ADFS-CA.
  • --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.

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] ist der Ausgabespeicherort der 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]

Fazit

Ihr Unternehmen betreibt einen ADFS-Server, der als OpenID-Anbieter fungiert. Ihr OpenID-Anbieter kennt die Anwendung kubectl und weiß, dass kubectl die Bereiche openid und allatclaims anfordern kann.

Das LDAP-Attribut Token-Groups Qualified Names in Ihrer AD-Datenbank wird dem Anspruch groups in Ihrem OpenID-Anbieter zugeordnet. Der Anbieter gibt Tokens zurück, die die Mitarbeiter-ID, die Aussteller-ID, den openid-Anspruch und den groups-Anspruch enthalten. Der Anspruch groups listet die Sicherheitsgruppen auf, zu denen ein Mitarbeiter gehört.

Weitere Informationen

Zurück
Mit OIDC authentifizieren
Weiter
Audit-Logging