Diese Seite wurde von der Cloud Translation API übersetzt.

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 Ihre vorhandenen Active Directory-basierten Nutzer auf Ihre AlloyDB Omni-Datenbank zugreifen können. Die Active Directory-Integration bietet die Autorisierung mit 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 kubectl-Befehlszeilentools vertraut sind. Weitere Informationen finden Sie unter Befehlszeilentool (kubectl).

Hinweise

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

Ein in einer Kubernetes-Umgebung bereitgestellter AlloyDB Omni-Cluster
Ein Active Directory-Server-Keytab

Von AlloyDB Omni Kubernetes-Operator 1.4.0 zu 1.5.0 migrieren

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

So migrieren Sie zur AlloyDB Omni-Operatorversion 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. Ersetzen Sie spec.dbclusterRef durch den Namen des Ziel-DB-Clusters.
3. Ersetzen Sie spec.keytabSecretRef durch den Namen des Keytab-Secrets.
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 vorhandene pg_ident.conf rules (falls vorhanden) in das Feld spec.pgIdentEntries.
6. Wenden Sie dieses neue Manifest an, z. B. kubectl apply -f user-auth-crd.yaml.
Entfernen Sie die Vorschaukonfiguration 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. HBA-Regeln (hostbasierte Authentifizierung), Ident-Regeln und Keytab-Dateianmerkungen.
2. Löschen Sie die von Ihnen erstellten ConfigMaps pg_hba und pg_ident.
3. Wenden Sie das aktualisierte DBCluster-Manifest noch einmal an.

Active Directory-Unterstützung konfigurieren

Secret mit dem Keytab erstellen und anwenden:
```
apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT
```
Im Folgenden sehen Sie ein Beispiel für einen Befehl, mit dem ein 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 cat postgres.keytab | base64, um die base64-codierte Keytab zu erhalten.
Wenden Sie das folgende benutzerdefinierte Manifest für die Authentifizierung 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 des von Ihnen erstellten Keytabs.
- 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 dieser Anmeldeansatz fehlschlägt, wird die passwortbasierte Authentifizierung als Fallback verwendet.
  
  Weitere Informationen finden Sie unter Die 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 Optionsfeld in der Datei pg_hba.conf an. Weitere Informationen finden Sie unter Identitätskarten.
  
  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 bei der Datenbank an. kinit muss in dem Client aktiviert sein, mit dem Sie eine Verbindung herstellen. In diesem Beispiel sind auf dem postgres-client-Pod kinit und psql installiert. Er ist so konfiguriert, dass er mit dem psql-Client eine Verbindung zum AlloyDB Omni-Cluster herstellt.
```
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.
```
SQL-Abfragen ausführen.
```
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