Diese Seite wurde von der Cloud Translation API übersetzt.

Fleet-Mitgliedercluster für die LDAP-Authentifizierung einrichten

In diesem Dokument wird beschrieben, wie Clusteradministratoren oder Anwendungsbetreiber Kubernetes-Cluster so konfigurieren können, dass die Authentifizierung über einen Drittanbieter-LDAP-Anbieter (Lightweight Directory Access Protocol) wie Microsoft Entra ID oder Google LDAP unterstützt wird. Weitere Informationen finden Sie unter Authentifizierung mit Identitäten von Drittanbietern.

Beschränkungen

Sie müssen einen Clustertyp verwenden, der LDAP unterstützt.

Hinweise

Install the Google Cloud CLI.
Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.
Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren:
```
gcloud init
```
Aktualisieren Sie die gcloud CLI nach der Initialisierung und installieren Sie die erforderlichen Komponenten:
```
gcloud components update
gcloud components install kubectl
```
Achten Sie darauf, dass Ihr Plattformadministrator Ihnen alle erforderlichen Anbieterinformationen zur Verfügung gestellt hat. Weitere Informationen finden Sie unter LDAP-Anbieter für die Authentifizierung bei Clustern konfigurieren.

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

Ihr Cluster benötigt ein Dienstkonto-Secret, um sich beim LDAP-Server zu authentifizieren und Nutzerdetails abzurufen. Die LDAP-Authentifizierung unterstützt die folgenden Mechanismen:

Basisauthentifizierung, bei der Sie einen Nutzernamen und ein Passwort verwenden.
Clientzertifikatsauthentifizierung, bei der Sie einen privaten Clientschlüssel und ein Clientzertifikat verwenden.

Sie oder Ihr Plattformadministrator sollten diese Informationen zu Ihrem Anbieter haben, indem Sie die Schritte unter LDAP-Anbieter für die Authentifizierung bei Clustern konfigurieren ausgeführt haben. Um die Anmeldedaten für den LDAP-Server für den Cluster verfügbar zu machen, müssen Sie ein Kubernetes-Secret mit den LDAP-Anmeldedaten erstellen. Die folgenden Beispiele zeigen, wie Secrets für beide Authentifizierungstypen konfiguriert werden. In den Beispielen wird gezeigt, wie das Secret auf den Namespace anthos-identity-service 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.

In den Beispielen wird gezeigt, wie das Secret auf den Namespace anthos-identity-service angewendet wird. Standardmäßig haben Systemkomponenten die Berechtigung, Secrets in diesem Namespace zu lesen. 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 default-ServiceAccount im Namespace anthos-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

Wenn Sie die Authentifizierung für einen Cluster mit LDAP konfigurieren möchten, fügen Sie einer benutzerdefinierten Kubernetes-Ressource mit dem Namen ClientConfig die folgenden Informationen hinzu:

Informationen zum Identitätsanbieter und den Parametern, die er benötigt, um Nutzerinformationen zurückzugeben.
Der Name und der Namespace des Secrets, das Sie im vorherigen Abschnitt erstellt und angewendet haben. Dadurch kann sich der Cluster beim LDAP-Server authentifizieren.

Bearbeiten Sie die default ClientConfig im Namespace kube-public, um Ihren Cluster zu konfigurieren:

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
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      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

Sie können derselben ClientConfig mehrere OIDC-, LDAP- und SAML-Identitätsanbieterkonfigurationen hinzufügen. Der Cluster versucht, sich mit jeder Konfiguration in der Reihenfolge zu authentifizieren, in der sie definiert sind. Der Vorgang wird nach der ersten erfolgreichen Authentifizierung beendet. Im folgenden Beispiel für ClientConfig werden mehrere Identitätsanbieter in einer bestimmten Reihenfolge definiert:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

ClientConfig-LDAP-Felder

In der folgenden Tabelle sind die Felder des ClientConfig-ldap-Objekts beschrieben. Welche Felder Sie hinzufügen müssen, hängt von Ihren Identitätsanbieter-Tokens und der Konfiguration des Anbieters durch Ihren Plattformadministrator ab.

Feld	Erforderlich	Beschreibung	Format
Name	Ja	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	Ja	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	Ja	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	Ja	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	Ja	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 von externen Anbietern auf Cluster ein.

Fleet-Mitgliedercluster für die LDAP-Authentifizierung einrichten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.