Auf dieser Seite wird die AlloyDB Omni-Version 18.3.0 mit der Bereitstellungsoption Container-Orchestrator dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Unterstützung für Active Directory-Nutzer in Kubernetes einbinden

Wählen Sie eine Dokumentationsversion aus:

In diesem Dokument wird beschrieben, wie Sie die Active Directory Integration in Ihrem Kubernetes-basierten AlloyDB Omni-Datenbankcluster aktivieren, damit Sie Ihren vorhandenen Active Directory-basierten Nutzern Zugriff auf Ihre AlloyDB Omni-Datenbank gewähren können. Die Active Directory-Integration bietet die Autorisierung über GSSAPI für Nutzer, die mit dem Kerberos-Mechanismus authentifiziert wurden, um auf AlloyDB Omni zuzugreifen.

Weitere Informationen finden Sie unter Active Directory – Übersicht.

In diesem Dokument wird davon ausgegangen, dass Sie mit dem Anwenden von Kubernetes-Manifestdateien und der Verwendung des Befehlszeilentools kubectl vertraut sind. Weitere Informationen finden Sie unter Befehlszeilentool (kubectl).

Hinweis

Für die Aktivierung der Active Directory-Integration benötigen Sie Folgendes:

Einen AlloyDB Omni-Cluster, der in einer Kubernetes-Umgebung bereitgestellt wurde
Eine Keytab für den Active Directory-Server

Von AlloyDB Omni Kubernetes-Operator 1.4.0 zu 1.5.0 migrieren

Wenn Sie die Active Directory-Integration in AlloyDB Omni-Operator-Version 1.4.0 oder früher verwenden, müssen Sie zu AlloyDB Omni-Operator-Version 1.5.0 migrieren.

So migrieren Sie zu AlloyDB Omni-Operator-Version 1.5.0:

Führen Sie ein Upgrade des AlloyDB Omni-Operators auf Version 1.5.0 durch.
Erstellen Sie eine benutzerdefinierte Authentifizierungsressource.
1. Erstellen Sie ein neues Manifest für die UserDefinedAuthentication-Ressource.
2. Füllen Sie spec.dbclusterRef mit dem Namen des Ziel-DBClusters aus.
3. Füllen Sie spec.keytabSecretRef mit dem Namen des Keytab-Secrets aus.
4. Kopieren Sie die vorhandenen pg_hba.conf-Regeln, die für die Active Directory- und Kerberos-Authentifizierung relevant sind, in das Feld spec.pgHbaEntries.
5. Kopieren Sie die vorhandenen pg_ident.conf rules (falls vorhanden) in das spec.pgIdentEntries Feld.
6. Wenden Sie dieses neue Manifest an, z. B. kubectl apply -f user-auth-crd.yaml.
Entfernen Sie die Preview-Konfiguration und stellen Sie den Cluster noch einmal bereit.
1. Entfernen Sie in der DBCluster-Ressourcendefinition alle Anmerkungen, die Sie zuvor zum Konfigurieren der Active Directory-Integration verwendet haben, z. B. hostbasierte Authentifizierungsregeln (HBA), Ident-Regeln und Anmerkungen zur Keytab-Datei.
2. Löschen Sie die von Ihnen erstellten pg_hba- und pg_ident-ConfigMaps.
3. Wenden Sie das aktualisierte DBCluster-Manifest noch einmal an.

Active Directory-Unterstützung konfigurieren

Erstellen und wenden Sie ein Secret mit der Keytab an:
```
apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT
```
Das folgende Beispiel zeigt einen Befehl, mit dem eine Keytab auf dem Active Directory-Server generiert wird:
```
ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH
```
ALLOYDB_HOST ist der Host, der auf den DBCluster oder die DBCluster-IP-Adresse verweist.

Hinweis: Verwenden Sie einen Befehl wie den folgenden, um die base64-codierte Keytab zu erhalten: cat postgres.keytab | base64.
Wenden Sie das folgende benutzerdefinierte Manifest für die Authentifizierungsressource an:
```
apiVersion: alloydbomni.dbadmin.goog/v1
kind: UserDefinedAuthentication
metadata:
  name: USER_DEFINED_AUTHENTICATION_NAME
  namespace: DB_CLUSTER_NAMESPACE
spec:
  dbclusterRef:
    name: DB_CLUSTER_NAME
  keytabSecretRef:
    name: KEYTAB_SECRET_NAME
  pgHbaEntries:
    PG_HBA_ENTRIES
  pgIdentEntries:
    PG_IDENT_ENTRIES
```
Ersetzen Sie Folgendes:
- USER_DEFINED_AUTHENTICATION_NAME: der Name der UserDefinedConfiguration, z. B. DB_CLUSTER_NAME-ad-auth.
- DB_CLUSTER_NAMESPACE: der Kubernetes-Namespace für diesen Sicherungsplan. Der Namespace muss mit dem Namespace des Datenbankclusters übereinstimmen.
- DB_CLUSTER_NAME: der Name Ihres Datenbankclusters, den Sie beim Erstellen zugewiesen haben.
- KEYTAB_SECRET_NAME: der Name der von Ihnen erstellten Keytab.
- PG_HBA_ENTRIES: pg_hba.conf-Einträge als Stringliste. Diese Einträge überschreiben die Standardeinträge in pg_hba.conf. Wenn Sie eine ungültige Konfiguration hinzufügen, können sich Nutzer nicht anmelden.
  
  Im vorherigen Beispiel haben Sie Einträge für die GSS-basierte Authentifizierung und dann für die passwortbasierte Authentifizierung hinzugefügt. Das bedeutet, dass der Nutzer mit der GSS-API angemeldet ist. Wenn diese Anmeldemethode fehlschlägt, wird die passwortbasierte Authentifizierung als Fallback verwendet.
  
  Weitere Informationen finden Sie in der Datei pg_hba.conf.
- PG_IDENT_ENTRIES: pg_ident.conf-Einträge als Stringliste. Wenn Sie die Zuordnung von Nutzernamen implementieren möchten, geben Sie map= im Feld „Optionen“ in der pg_hba.conf Datei an. Weitere Informationen finden Sie unter Ident-Zuordnungen.
  
  Sehen Sie sich folgendes Beispiel an:
```
 apiVersion: v1
 kind: Secret
 metadata:
   name: db-keytab-dbcluster-sample
 type: Opaque
 data:
   krb5.keytab: |
     DUMMY_KEYTAB
 ---
 apiVersion: alloydbomni.dbadmin.goog/v1
 kind: UserDefinedAuthentication
 metadata:
   name: dbcluster-sample-ad-auth
 spec:
   dbclusterRef:
     name: dbcluster-sample
   keytabSecretRef:
     name: db-keytab-dbcluster-sample
   pgHbaEntries:
     - hostgssenc all           all      0.0.0.0/0     gss
     - hostgssenc all           all      ::1/128       gss
     - hostssl all all 0.0.0.0/0 scram-sha-256
     - hostssl all all ::/0 scram-sha-256
   pgIdentEntries:
     - usermap  active_directory_user postgres_user
```

Datenbankrollen als Active Directory-Nutzer erstellen

Erstellen Sie in Ihrer Datenbank eine Rolle, die dem Active Directory-Nutzer entspricht. Wenn Sie eine Rolle für Ihren Active Directory-Nutzer erstellen möchten, stellen Sie eine Verbindung zum Cluster her und führen Sie die folgenden Befehle aus:
```
username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;
```
Melden Sie sich mit dem Active Directory-Nutzer in der Datenbank an. kinit muss auf dem Client aktiviert sein, von dem aus Sie die Verbindung herstellen. In diesem Beispiel sind kinit und psql im Pod postgres-client installiert und so konfiguriert, dass eine Verbindung zum AlloyDB Omni-Cluster mit dem psql-Client hergestellt wird.
```
kubectl exec -it postgres-client -n DB_CLUSTER_NAMESPACE -- bash
root:/# kinit USERNAME
Password for USERNAME@REALM:

root:/# psql -h HOSTNAME -d DB_NAME -U USERNAME@REALM
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.
```
Führen Sie SQL-Abfragen aus.
```
username=# select * from TABLE_NAME;
```

Active Directory-Authentifizierung deaktivieren

Führen Sie den folgenden Helm-Befehl aus, um die Active Directory-Authentifizierung zu deaktivieren:

helm upgrade alloydbomni-operator PATH_TO_CHART -n alloydb-omni-system --set userDefinedAuthentication.enabled=false

Der Befehl gibt die folgende Ausgabe zurück:

Release "alloydbomni-operator" has been upgraded. Happy Helming!
NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 2
TEST SUITE: None