Diese Seite wurde von der Cloud Translation API übersetzt.

GKE Identity Service mit LDAP einrichten

Dieses Dokument richtet sich an Clusteradministratoren oder Anwendungsoperatoren, die GKE Identity Service auf ihren Clustern einrichten. Sie erfahren, wie Sie GKE Identity Service auf Ihren Clustern mit Ihrem bevorzugten LDAP-Anbieter (Lightweight Directory Access Protocol) einrichten, einschließlich Microsoft Active Directory. Es wird davon ausgegangen, dass Sie oder Ihr Plattformadministrator bereits Anmeldedaten für Ihren LDAP-Anbieter erhalten haben, gemäß der Anleitung unter LDAP-Anbieter für GKE Identity Service einrichten.

Weitere Informationen zur Funktionsweise von GKE Identity Service und zu anderen Einrichtungsoptionen finden Sie in der Übersicht. Informationen zum Zugriff auf einen Cluster mit diesem Dienst als Entwickler oder anderer Clusternutzer finden Sie unter Mit GKE Identity Service auf Cluster zugreifen.

GKE Identity Service mit LDAP kann derzeit nur mit GKE on VMware (Nutzercluster) und GKE on Bare Metal verwendet werden.

Hinweise

Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:
- Die neueste Version der Google Cloud CLI, die gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud, enthält. Informationen zur Installation des Google Cloud CLI finden Sie in der Installationsanleitung.
- kubectl zum Ausführen von Befehlen für Kubernetes-Cluster. Informationen zur Installation von kubectl finden Sie in der Installationsanleitung.
Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloud verwenden, sind diese Tools für Sie installiert.
Achten Sie darauf, dass die gcloud CLI für die Verwendung mit Ihrem Projekt initialisiert wurde.

Während der Einrichtung müssen Sie möglicherweise die Dokumentation des LDAP-Servers lesen. Im Folgenden werden die Konfigurationen für einige beliebte LDAP-Anbieter erläutert. Außerdem erfahren Sie, wo Sie die erforderlichen Informationen finden, um sich beim LDAP-Server anzumelden und Ihre Cluster zu konfigurieren:

LDAP-Dienstkonto-Secret füllen

GKE Identity Service benötigt ein Dienstkonto-Secret, um sich beim LDAP-Server zu authentifizieren und Nutzerdetails abzurufen. Für die LDAP-Authentifizierung sind zwei Arten von Dienstkonten zulässig: die Basisauthentifizierung (mit einem Nutzernamen und einem Passwort zur Authentifizierung beim Server) oder ein Clientzertifikat (mit einem privaten Clientschlüssel und einem Clientzertifikat). Sie oder Ihr Plattformadministrator sollten diese Informationen zu Ihrem Anbieter haben, indem Sie die Schritte unter LDAP-Anbieter für GKE Identity Service einrichten ausgeführt haben.

Um die Anmeldedaten für den LDAP-Server für GKE Identity Service verfügbar zu machen, müssen Sie eine Kubernetes-Secret-Ressource mit den Anmeldedaten aus dem Abschnitt LDAP-Anbieter für GKE Identity Service einrichten erstellen.

Die folgenden Beispiele zeigen, wie Secrets für beide Dienstkontotypen konfiguriert werden. In den Beispielen wird gezeigt, wie das Secret auf den anthos-identity-service-Namespace angewendet wird.

Dies ist ein Beispiel für eine grundlegende Konfiguration eines Secrets bei der Basisauthentifizierung:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

Dabei ist SERVICE_ACCOUNT_SECRET_NAME der Name, den Sie für dieses Secret ausgewählt haben. Ersetzen Sie die Nutzernamen- und Passwortwerte durch den Nutzernamen und das Passwort, die Sie im vorherigen Schritt erhalten haben. USERNAME ist ein base64-codierter Nutzername PASSWORD ist ein base64-codiertes Passwort.

Dies ist ein Beispiel für die Konfiguration eines Secrets bei einem Clientzertifikat:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Dabei ist SERVICE_ACCOUNT_SECRET_NAME der Name, den Sie für dieses Secret ausgewählt haben. Ersetzen Sie das TLS-Zertifikat und die Schlüsselwerte durch das codierte Zertifikat und die Schlüsselwerte, die Sie im vorherigen Schritt erhalten haben.

Die Beispiele zeigen das Secret, das auf den Namespace anthos-identity-service angewendet wird. Dies ist unser empfohlener Ansatz. Das liegt daran, dass GKE Identity Service standardmäßig die Berechtigung zum Lesen von Secrets in anthos-identity-service hat. Wenn Sie einen anderen Namespace verwenden möchten, ändern Sie die Metadaten im Secret und fügen Sie dann eine neue RBAC-Richtlinie hinzu, um dem GKE Identity Service die Berechtigung zum Lesen von Secrets in diesem Namespace zu gewähren:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

Cluster konfigurieren

GKE Identity Service verwendet zum Konfigurieren Ihrer Cluster ClientConfig einen speziellen benutzerdefinierten Ressourcentyp von Kubernetes mit Feldern für Informationen zum Identitätsanbieter und den Parametern, die er zur Rückgabe von Nutzerinformationen benötigt. Die Konfiguration ClientConfig enthält auch den Secret-Namen und den Namespace aus dem Secret, das Sie im vorherigen Abschnitt erstellt und angewendet haben, damit sich GKE Identity Service beim LDAP-Server authentifizieren kann.

Bearbeiten Sie das KRM-Standardobjekt vom Typ clientconfig im Namespace kube-public, um die Konfiguration auf Ihren Cluster anzuwenden:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Dabei ist USER_CLUSTER_KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Wenn die kubeconfig mehrere Kontexte enthält, wird der aktuelle Kontext verwendet. Möglicherweise müssen Sie den aktuellen Kontext auf den richtigen Cluster zurücksetzen, bevor Sie den Befehl ausführen.

Im Folgenden sehen Sie das Format der ClientConfig-Konfiguration:

authentication:
  - name: NAME_STRING
    ldap:
      host: HOST_NAME
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      serviceAccountSecret:
        name: SERVICE_ACCOUNT_SECRET_NAME
        namespace: NAMESPACE
        type: SECRET_FORMAT
      user:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
        loginAttribute: LOGIN_ATTRIBUTE
      group:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE

In der folgenden Tabelle werden die Felder in der CRD von ClientConfig beschrieben:

Feld	Erforderlich	Beschreibung	Format
Name	yes	Ein Name zur Identifizierung dieser LDAP-Konfiguration	String
Host	Ja	Hostname oder IP-Adresse des LDAP-Servers. Der Port ist optional und standardmäßig 389, wenn nicht angegeben. Beispiel: `ldap.server.example.com` oder `10.10.10.10:389`.	String
certificateAuthorityData	Erforderlich für bestimmte LDAP-Verbindungstypen	Enthält ein Base64-codiertes, PEM-formatiertes Zertifizierungsstellen-Zertifikat für den LDAP-Server. Dies muss nur für `ldaps`- und `startTLS`-Verbindungen angegeben werden.	String
connectionType	yes	LDAP-Verbindungstyp, der beim Herstellen einer Verbindung zum LDAP-Server verwendet werden soll. Die Standardeinstellung ist `startTLS`. Der Modus `insecure` sollte nur für die Entwicklung verwendet werden, da die gesamte Kommunikation mit dem Server im Klartext erfolgt.	String
serviceAccountSecret
name	yes	Name des Kubernetes-Secrets, das die Anmeldedaten für das LDAP-Dienstkonto speichert.	String
Namespace	Ja	Namespace des Kubernetes-Secrets, das die Anmeldedaten für das LDAP-Dienstkonto speichert.	String
Typ	yes	Definiert das Format des Dienstkonto-Secrets, um verschiedene Arten von Secrets zu unterstützen. Wenn Sie `basic-auth` in der Secret-Konfiguration angegeben haben, ist dies `basic`, andernfalls `tls`. Wenn nicht angegeben, lautet die Standardeinstellung `basic`.	String
Nutzer
baseDN	Ja	Der Speicherort der Unterstruktur im LDAP-Verzeichnis, um nach Nutzereinträgen zu suchen.	String
Filter	no	Optionaler Filter, der bei der Suche nach dem Nutzer angewendet werden soll. Damit können Sie die Nutzerkonten, die sich anmelden dürfen, weiter einschränken. Wenn nicht angegeben, lautet die Standardeinstellung `(objectClass=User)`.	String
identifierAttribute	no	Bestimmt, welches Attribut nach der Authentifizierung als Identität des Nutzers verwendet werden soll. Dies unterscheidet sich vom Feld "loginAttribute", wodurch sich Nutzer mit einem Nutzernamen anmelden können. Die tatsächliche Kennzeichnung muss jedoch eine E-Mail-Adresse oder ein vollständiger Distinguished Name (DN) sein. Beispiel: Wenn Sie loginAttribute auf `sAMAccountName` und identifierAttribute auf `userPrincipalName` setzen, können sich Nutzer als`bsmith` anmelden. Die tatsächlichen RBAC-Richtlinien für den Nutzer würden jedoch so geschrieben werden: `bsmith@example.com`. Die Verwendung von `userPrincipalName` wird empfohlen, da dies für jeden Nutzer eindeutig ist. Wenn nicht angegeben, lautet die Standardeinstellung `userPrincipalName`.	String
loginAttribute	no	Der Name des Attributs, das dem Eingabenutzernamen entspricht. Damit wird der Nutzer in der LDAP-Datenbank gesucht, z. B. `(<LoginAttribute>=<username>)`. Es wird mit dem optionalen Filterfeld kombiniert. Die Standardeinstellung ist `userPrincipalName`.	String
group (optionales Feld)
baseDN	yes	Der Speicherort der Unterstruktur im LDAP-Verzeichnis, um nach Gruppeneinträgen zu suchen.	String
Filter	no	Optionaler Filter, der bei der Suche nach Gruppen verwendet wird, zu denen ein Nutzer gehört. Dies kann verwendet werden, um explizit auf bestimmte Gruppen einzuschränken, um die Anzahl der Gruppen zu reduzieren, die für jeden Nutzer zurückgegeben werden. Die Standardeinstellung ist `(objectClass=Group)`.	String
identifierAttribute	no	Der identifizierende Name jeder Gruppe, zu der ein Nutzer gehört. Wenn dieser Wert beispielsweise auf `distinguishedName` festgelegt ist, sollten RBACs und andere Gruppenerwartungen als vollständige DNs geschrieben werden. Wenn nicht angegeben, lautet die Standardeinstellung `distinguishedName`.	String

Nächste Schritte

Nachdem die Konfiguration angewendet wurde, richten Sie den Nutzerzugriff auf Cluster mit dem GKE Identity Service ein.