Version 1.6. Diese Version wird unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Darin sind die neuesten Patches und Updates zu Sicherheitslücken, Kontakten und Problemen mit Anthos-Clustern auf Bare-Metal aufgegführt. Weitere Informationen finden Sie in den Versionshinweisen. Dies ist nicht die neueste Version.

Identitätsverwaltung mit OIDC in Anthos-Cluster auf Bare Metal

Sie können sich bei Anthos-Cluster auf Bare Metal-Clustern mit OpenID Connect (OIDC) authentifizieren. OIDC ist eine Authentifizierungsebene, die auf OAuth 2.0 basiert und eine RESTful HTTP API angibt. Sie verwendet JSON als Datenformat.

Mit OIDC können Sie Ihren vorhandenen Identitätsanbieter zur Verwaltung der Nutzer- und Gruppenauthentifizierung in Anthos-Clustern auf Bare Metal-Clustern verwenden. Mit OIDC können Sie den Zugriff auf einen Anthos-Cluster in einem Bare Metal-Cluster verwalten. Dazu verwenden Sie die Standardverfahren in Ihrer Organisation zum Erstellen, Aktivieren und Deaktivieren von Konten. Außerdem haben Sie die Möglichkeit mit den Sicherheitsgruppen Ihrer Organisation den Zugriff auf einen Cluster oder auf bestimmte Dienste in einem Cluster zu konfigurieren. Der verwaltete Zugriff kann auf jeder Art von Anthos-Clustern auf Bare Metal-Clustern ausgeführt werden: "Administrator", "Nutzer", "Hybrid" oder "Eigenständig".

Anthos-Cluster auf Bare Metal unterstützen sowohl lokale als auch öffentlich erreichbare Identitätsanbieter. Beispielsweise können Sie eine lokale Active Directory Federation Services-Komponente verwenden. Sie können auch öffentlich zugängliche Identitätsanbieterdienste von Google oder Okta verwenden. Außerdem können Identitätsanbieterzertifikate von einer bekannten öffentlichen Zertifizierungsstelle (Certificate Authority, CA) oder von einer privaten Zertifizierungsstelle ausgestellt werden.

Nutzern stehen zwei OIDC-Authentifizierungsmethoden zur Verfügung:

  • OIDC-Authentifizierung über eine Befehlszeile, bei der Nutzer einen gcloud-Befehl ausführen und über eine browserbasierte Anmeldeseite/Einwilligung authentifiziert werden.

  • OIDC-Authentifizierung über die Google Cloud Console-UI, bei der sich Nutzer direkt über die Kubernetes-Clusterseite bei einem Cluster anmelden. Bei dieser Methode muss der Cluster bei Google Cloud registriert sein. Cluster werden automatisch während der Installation von Anthos-Cluster auf Bare Metal-Clustern registriert.

Beachten Sie, dass OIDC keine monitorlosen Workflows unterstützt: OIDC erfordert eine browserbasierte Authentifizierung, um Nutzer auf die Webseite des Identitätsanbieters weiterzuleiten und die Nutzer um Zustimmung und Kontoanmeldung/Passwort zu bitten.

OIDC- und Kubernetes-Zugriffssteuerung

Die OIDC-Authentifizierung wird häufig mit der rollenbasierten Zugriffssteuerung von Kubernetes (Role-Based Access Control, RBAC) kombiniert. Mit RBAC können Sie detaillierte Autorisierungsrichtlinien erstellen, mit denen Sie definieren, welche Nutzer oder Gruppen bestimmte Vorgänge für eine bestimmte Gruppe von Clusterressourcen ausführen können.

OIDC-Authentifizierung – Übersicht

Eine typische OIDC-Authentifizierung umfasst die folgenden Schritte:

  1. Ein Nutzer meldet sich bei einem OpenID-Anbieter an, indem er einen Nutzernamen und ein Passwort angibt.
  2. Der OpenID-Anbieter stellt ein ID-Token für den Nutzer aus.

  3. Das Token wird vom Anbieter signiert und über eine vorkonfigurierte Callback-URL zurückgegeben.

  4. Eine Anwendung, die im Namen des Nutzers handelt, sendet eine HTTPS-Anfrage an den Kubernetes-API-Server. Die Anfrage enthält das ID-Token des Nutzers im Anfrageheader.

  5. Der Kubernetes API-Server überprüft das ID-Token mit dem Zertifikat des Anbieters und parst das Token, um die Identität des Nutzers und gegebenenfalls die Gruppen des Nutzers zu ermitteln.

In der Regel sind bei der OIDC-Einrichtung und -Authentifizierung drei Personen beteiligt:

  • Der Organisationsadministrator, der einen OpenID-Anbieter auswählt und die Clientanwendungen beim Anbieter registriert.

  • Ein Plattformadministrator, der einen oder mehrere Cluster und Authentifizierungskonfigurationsdateien für Nutzer erstellt, die die Cluster verwenden.

  • Einen Anwendungsoperator oder Entwickler, der Arbeitslasten auf einem oder mehreren Clustern ausführt und OIDC zur Authentifizierung verwendet.

Sie können jeden zertifizierten OpenID-Anbieter verwenden. Die Anbieter sind von der OpenID Foundation zertifiziert. Der genaue Registrierungsprozess hängt vom Anbieter ab, umfasst aber normalerweise die folgenden Schritte:

  1. Ermitteln Sie den Aussteller-URI des Anbieters. Hier sendet die gcloud-Befehlszeile oder die Google Cloud Console Authentifizierungsanfragen.

  2. Stellen Sie dem Anbieter die Weiterleitungs-URLs für die gcloud-Befehlszeile und die Cloud Console bereit.

  3. Erstellen Sie eine Client-ID und einen Clientschlüssel. Sowohl die gcloud-Befehlszeile als auch die Cloud Console verwenden diese Client-ID/Clientschlüssel zur Authentifizierung beim OpenID-Anbieter.

  4. Benutzerdefinierten Umfang festlegen und Anforderungen für Sicherheitsgruppen anfordern Im Allgemeinen sollten Sie Ihre RBAC-Richtlinien für Cluster auf Basis von Gruppen statt von Nutzern definieren, um die Richtlinien stabiler und prüfbar zu machen. Die meisten OIDC-Anbieter umfassen Gruppenanforderungen in ID-Tokens, sofern die jeweiligen Bereiche angefragt wurden. Spezifische Gruppenansprüche und -bereiche sind bei den OIDC-Anbietern unterschiedlich, daher erfordern diese anbieterspezifischen Bereiche und Anforderungen eine Anpassung.

Bevor ein neuer Anthos-Cluster auf einem Bare Metal-Cluster installiert wird, erhält der Plattformadministrator normalerweise die OIDC-Konfiguration vom Organisationsadministrator und konfiguriert die relevanten OIDC-Felder in der Clusterkonfiguration.

Nach Abschluss der Clusterinstallation erhält der Plattformadministrator die Konfigurationsdateien für die Authentifizierung und gibt sie für die Befehlszeilennutzer frei. Normalerweise teilt der Plattformadministrator die Authentifizierungskonfiguration, indem er die Dateien auf einem sicheren Host hostet oder mithilfe interner Tools auf die Rechner der einzelnen Nutzer verschiebt. Die Befehlszeilennutzer authentifizieren dann den neuen Cluster mit den freigegebenen Konfigurationsdateien.

Der Plattformadministrator kann auch die Details der Authentifizierungskonfiguration für mehrere Cluster in einer einzelnen Konfigurationsdatei für die Authentifizierung speichern.

Beachten Sie, dass Cloud Console-Nutzer diese Konfigurationsdateien nicht benötigen. Wenn Nutzer die Cloud Console aufrufen, können sie Authenticate with the Identity Provider für den Cluster konfigurieren und dann auf Login. klicken.