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 nur mit Google Distributed Cloud-Deployments auf VMware (Nutzercluster) und auf Bare Metal verwendet werden.

Vorbereitung

1. Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:
   • Die neueste Version des 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. Wenn Sie kubectl installieren müssen, lesen Sie den Installationsleitfaden. Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloud verwenden, sind diese Tools bereits für Sie installiert.
2. 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:

• OpenLDAP
• Azure AD
• Microsoft Active Directory
• Google LDAP

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

Ersetzen Sie SERVICE_ACCOUNT_SECRET_NAME durch den Namen, 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 erteilen:

---
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 einen speziellen benutzerdefinierten Ressourcentyp (CRD) für Kubernetes zum Konfigurieren Ihrer Cluster mit dem Namen ClientConfig, mit Feldern für Informationen zum Identitätsanbieter und den Parametern, die zum Zurückgeben von Nutzerinformationen erforderlich sind. 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

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den 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:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  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:

Nächste Schritte

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