Auf dieser Seite wird die AlloyDB Omni-Version 17.5.0 mit der Bereitstellungsoption Kubernetes 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-Gruppen in Kubernetes einbinden

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie die gruppenbasierte Authentifizierung und Autorisierung von Active Directory in AlloyDB Omni einrichten und verwalten, das in Kubernetes bereitgestellt wird. Die gruppenbasierte Unterstützung von Active Directory automatisiert die Verwaltung von PostgreSQL-Rollenmitgliedschaften basierend auf den Gruppenmitgliedschaften eines Nutzers in Ihrem Active Directory. Dadurch wird die Nutzerverwaltung vereinfacht und sichergestellt, dass die Berechtigungen synchron sind. Weitere Informationen finden Sie in der Übersicht zu Active Directory.

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

Workflow für die Active Directory-Integration

Die Active Directory-Integration wird mit einer PostgreSQL-Erweiterung (google_pg_auth) im folgenden Workflow implementiert:

Nutzeranmeldung: Ein Nutzer authentifiziert sich bei AlloyDB Omni mit seinen Standardanmeldedaten für Active Directory über die Generic Security Services Application Programming Interface (GSSAPI).
Automatische Rollenerstellung: Wenn keine entsprechende PostgreSQL-Rolle für den Nutzer vorhanden ist, erstellt das System automatisch eine, z. B. CREATE ROLE "user@REALM" WITH LOGIN;.
LDAP-Gruppenprüfung: Das System stellt eine sichere Verbindung zu Ihrem Active Directory über LDAP her, um die aktuellen Gruppenmitgliedschaften des Nutzers abzurufen.
Synchronisierung der Mitgliedschaft: Das System vergleicht die Active Directory-Gruppen des Nutzers mit den von Ihnen konfigurierten Zuordnungen.
- Wenn der Nutzer Mitglied einer zugeordneten Active Directory-Gruppe, aber nicht der entsprechenden PostgreSQL-Gruppe ist, wird ihm die Mitgliedschaft gewährt.
- Wenn der Nutzer nicht Mitglied einer zugeordneten Active Directory-Gruppe, aber der entsprechenden PostgreSQL-Gruppe ist, wird die Mitgliedschaft des Nutzers widerrufen.
Anmeldung abgeschlossen: Die Verbindung des Nutzers wird abgeschlossen und er ist in der Datenbank angemeldet. Die Berechtigungen des Nutzers werden durch die PostgreSQL-Rollen bestimmt, denen er angehört. Diese sind mit seinem Active Directory-Gruppenstatus synchron.

Diese Synchronisierung erfolgt automatisch bei jeder Nutzeranmeldung. So wird sichergestellt, dass die PostgreSQL-Zugriffsrechte den aktuellen Status Ihres Active Directory widerspiegeln.

Hinweis

Bevor Sie die Unterstützung für Active Directory-Gruppen in AlloyDB Omni einbinden, müssen die folgenden Voraussetzungen erfüllt sein.

GSSAPI-Authentifizierung: Die GSSAPI-basierte Authentifizierung muss für Ihre AlloyDB Omni-Instanz konfiguriert und betriebsbereit sein. Weitere Informationen finden Sie unter Active Directory in AlloyDB Omni einbinden.
PostgreSQL-Gruppenrollen: Sie müssen die PostgreSQL-Gruppenrollen, die Sie Active Directory-Gruppen zuordnen möchten, manuell erstellen, wie im folgenden Beispiel gezeigt:
```
CREATE ROLE "postgres_developers";
CREATE ROLE "postgres_read_only";
```
Berechtigungen: Sie müssen die Datenbankberechtigungen, z. B. SELECT und INSERT, manuell diesen PostgreSQL-Gruppenrollen zuweisen. Die Integration verwaltet nur die Mitgliedschaft, aber nicht die Berechtigungen der Gruppen selbst, wie im folgenden Beispiel gezeigt:
```
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO postgres_read_only;
GRANT USAGE ON SCHEMA finance TO postgres_developers;
GRANT USAGE ON SCHEMA sales TO postgres_read_only;
GRANT SELECT, INSERT ON finance.transactions TO postgres_developers;
```

Unterstützung für Active Directory-Gruppen konfigurieren

Wenn Sie die Unterstützung für Active Directory-Gruppen konfigurieren möchten, müssen Sie eine benutzerdefinierte Ressource vom Typ UserDefinedAuthentication auf Ihren vorhandenen Datenbankcluster anwenden.

Konfigurieren Sie AlloyDB Omni mit den Anmeldedaten des LDAP-Servers. Wenden Sie das folgende Manifest für die benutzerdefinierte 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
ldapConfiguration:
   enableGroupMapping: true
   ldapURI: LDAP_URI
   ldapBaseDN: LDAP_BASE_DN
   ldapBindDN: LDAP_BIND_DN
   cacheTTLSeconds: CACHE_TTL_SECONDS
   ldap_connection_timeout_ms: LDAP_CONNECTION_TIMEOUT
   ldapBindPasswordSecretRef:
     name: LDAP_PASSWORD_SECRET_REF
   ldapsCertificateSecretRef:
     name: LDAPS_CERT_SECRET_REF
   allow_unmapped_ad_users: ALLOW_UNMAPPED_AD_USERS

Ersetzen Sie die folgenden Werte:

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.
LDAP_URI: Die LDAP-Server-URI, z. B. ldaps://ad.example.com:636.
LDAP_BASE_DN: Der Basis-DN für LDAP-Suchen. z.B. DC=ad,DC=alloydb,DC=COM
LDAP_BIND_DN: Der Distinguished Name (DN) für den LDAP-Bind-Nutzer.
LDAP_PASSWORD_SECRET_REF: Die Referenz zum Kubernetes-Secret mit dem LDAP-Passwort. Der Schlüssel dieses Secrets muss password sein.
LDAPS_CERT_SECRET_REF: (Optional) Die Referenz zum Kubernetes-Secret mit dem LDAPS-Zertifikat. Der Schlüssel dieses Secrets muss ldap.crt sein.
CACHE_TTL_SECONDS: (Optional) Die maximale Wartezeit in Sekunden, bevor eine Synchronisierung der LDAP-Gruppenmitgliedschaft ausgelöst wird. Der Standardwert ist 3600 Sekunden.
LDAP_CONNECTION_TIMEOUT: (Optional) Das Zeitlimit für die LDAP-Verbindung in Millisekunden. Der Standardwert ist 5000 ms.
ALLOW_UNMAPPED_AD_USERS: (Optional) Wenn auf true gesetzt, können sich auch Nutzer anmelden, die nicht Mitglied einer zugeordneten Active Directory-Gruppe sind. Der Standardwert ist false.

Sehen Sie sich folgendes Beispiel an:

apiVersion: v1
kind: Secret
metadata:
  name: ldaps-secret
type: Opaque
data:
  ldap.crt: LDAPS_CERTIFICATE_CONTENT_BASE64_ENCODED
---
apiVersion: v1
kind: Secret
metadata:
  name: ldap-password-dbcluster-sample
type: Opaque
data:
  password: LDAPS_PASSWORD_CONTENT_BASE64_ENCODED
---
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-dbcluster-sample
type: Opaque
data:
  dbcluster-sample: POSTGRES_PASSWORD
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 16.8.0
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-dbcluster-sample
    resources:
      memory: 5Gi
      cpu: 1
      disks:
      - name: DataDisk
        size: 10Gi
---
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
  ldapConfiguration:
    enableGroupMapping: true
    ldapURI: ldaps://ad.alloydb.com:636
    ldapBaseDN: DC=ad,DC=alloydb,DC=COM
    ldapBindDN: read-only-admin@ad.alloydb.com
    cacheTTLSeconds: 60
    ldapBindPasswordSecretRef:
      name: ldap-password-dbcluster-sample
    ldapsCertificateSecretRef:
      name: ldaps-secret

Gruppenzuordnungen verwalten

Sie können Zuordnungen zwischen Active Directory-Gruppen und PostgreSQL-Rollen mit SQL-Funktionen erstellen und verwalten.

Beim Cluster anmelden und die Erweiterung laden

Stellen Sie eine Verbindung zu AlloyDB Omni her, das in Kubernetes ausgeführt wird.

export DBPOD=`kubectl get pod --selector=alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}'`

kubectl exec -ti $DBPOD -n DB_CLUSTER_NAMESPACE -c database -- psql -h localhost -U postgres
postgres=# CREATE EXTENSION google_pg_auth;
CREATE EXTENSION

Gruppenzuordnung erstellen

Verwenden Sie die Funktion map_ad_group(), um eine Active Directory-Gruppe einer bereits erstellten PostgreSQL-Gruppenrolle zuzuordnen.

SELECT google_pg_auth.map_ad_group(ad_group_name TEXT, ad_group_sid TEXT, pg_role_name TEXT);

Im folgenden Beispiel wird die Active Directory-Gruppe ad-developers der PostgreSQL-Rolle pg-developers zugeordnet:

SELECT google_pg_auth.map_ad_group('ad-developers', 'S-1-5-21-.....', 'postgres_read_only');

Verwenden Sie den folgenden Befehl auf Ihrem Active Directory-Server, um die SID für eine bestimmte Gruppe in Active Directory abzurufen:

C:\Users\Admin> Get-ADGroup -Identity ad-developers | select SID
            
             SID
-----------------------------------------------
S-1-5-21-3168537779-1985441202-1799118680-1612

Gruppenzuordnung entfernen

Verwenden Sie die Funktion unmap_ad_group(), um eine vorhandene Zuordnung zu entfernen. Dadurch wird die Synchronisierung für diese Gruppe beendet. Mit der Funktion unmap_ad_group() werden Nutzer nicht aus der PostgreSQL-Gruppe entfernt, wenn sie bereits Mitglieder sind.

SELECT google_pg_auth.unmap_ad_group(ad_group_sid TEXT, pg_role_name TEXT);

Sehen Sie sich folgendes Beispiel an:

SELECT google_pg_auth.unmap_ad_group('S-1-5-21-.....', ''postgres_read_only'');

Nutzerzuordnung erstellen

Verwenden Sie die Funktion map_ad_user(), um einen einzelnen Active Directory-Nutzer einer bereits erstellten PostgreSQL-Rolle zuzuordnen.

SELECT google_pg_auth.map_ad_user(ad_username TEXT, pg_role_name TEXT);

Wenn Sie beispielsweise den Active Directory-Nutzer quinn@google.com der PostgreSQL-Rolle pg-developers zuordnen möchten, gehen Sie so vor:

SELECT google_pg_auth.map_ad_user('quinn@google.com', ''postgres_read_only'');

Nutzerzuordnung entfernen

Verwenden Sie die Funktion unmap_ad_user(), um eine vorhandene Zuordnung zu entfernen.

SELECT google_pg_auth.unmap_ad_user(ad_username TEXT, pg_role_name TEXT);

Wenn Sie beispielsweise die Zuordnung des Active Directory-Nutzers quinn@google.com zur PostgreSQL-Rolle pg-developers aufheben möchten, gehen Sie so vor:

SELECT google_pg_auth.unmap_ad_user('quinn@google.com', ''postgres_read_only'');

Verbindung zur AlloyDB Omni-Datenbank herstellen

Melden Sie sich mit dem Active Directory-Nutzer in der AlloyDB Omni-Datenbank an. kinit muss auf dem Client aktiviert sein, von dem aus Sie die Verbindung herstellen.

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

root@postgres-client:/# kinit AD_USER_NAME
Password for user1REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U AD_USER_NAME -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

user1=#

Ihr Zugriff in der AlloyDB Omni-Datenbank wird automatisch anhand der folgenden Faktoren bestimmt:

Ihre aktuelle Mitgliedschaft in Active Directory-Gruppen.
Die vom Administrator definierten Zuordnungen zwischen diesen Active Directory-Gruppen und den PostgreSQL-Rollen.
Die Berechtigungen, die der Administrator diesen PostgreSQL-Rollen gewährt hat.

Wenn Sie sich zum ersten Mal verbinden, wird Ihre PostgreSQL-Nutzerrolle (your_ad_user@YOURDOMAIN.COM) automatisch erstellt.

Bei jeder Anmeldung prüft das System Ihre aktuellen Active Directory-Gruppenmitgliedschaften und aktualisiert Ihre entsprechenden PostgreSQL-Rollenmitgliedschaften. Sie müssen keine besonderen Maßnahmen ergreifen, damit diese Synchronisierung erfolgt.

Beispiel für eine Datenbankverbindung

Im folgenden Beispiel ist der Nutzer Quinn Mitglied einer Active Directory-Gruppe namens ad_developers. Der Administrator hat ad_developers einer PostgreSQL-Rolle namens postgres_read_only zugeordnet. Diese Rolle hat Lesezugriff auf eine Tabelle namens sales. Wenn sich der Nutzer anmeldet, kann er auf die Tabelle zugreifen.

root@postgres-client:/# kinit quinnREALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinnREALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will be run successfully

Im folgenden Beispiel wird Quinn aus der Gruppe ad_developers in Active Directory entfernt.

root@postgres-client:/# kinit quinnREALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinnREALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will fail

Beschränkungen

Manuelle Gruppen- und Berechtigungsverwaltung: Mit dieser Funktion wird nur die Mitgliedschaft von Nutzern in vorhandenen PostgreSQL-Gruppen automatisiert. Das Erstellen dieser Gruppen und das Gewähren ihrer Berechtigungen ist eine manuelle Verwaltungsaufgabe.
Synchronisierungslatenz: Die Mitgliedschaft wird nur synchronisiert, wenn sich ein Nutzer anmeldet. Alle Änderungen, die an der Gruppenmitgliedschaft eines Nutzers in Active Directory vorgenommen werden, werden erst bei der nächsten Anmeldesitzung des Nutzers in AlloyDB Omni berücksichtigt.
Leistung: Die LDAP-Suche erhöht die Latenz beim ersten Anmeldevorgang des Nutzers geringfügig. Durch das Caching wird diese Latenz bei nachfolgenden Anmeldungen innerhalb der konfigurierten Gültigkeitsdauer (auth_cache_ttl_sec) reduziert.
Fehlerbehebung: Wenn der LDAP-Server nicht erreichbar ist oder andere Fehler während der Synchronisierung auftreten, protokolliert AlloyDB Omni den Fehler. Die Anmeldung des Nutzers ist jedoch weiterhin erfolgreich, da die GSSAPI-Authentifizierung erfolgreich war. Nur die Synchronisierung der Gruppenmitgliedschaft für diese Sitzung schlägt fehl.