Diese Seite wurde von der Cloud Translation API übersetzt.

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

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie die Active Directory-basierte Authentifizierung und Autorisierung für Gruppen in AlloyDB Omni einrichten und verwalten, die in Kubernetes bereitgestellt werden. Die Active Directory-basierte Unterstützung automatisiert die Verwaltung von PostgreSQL-Rollenmitgliedschaften basierend auf den Gruppenmitgliedschaften eines Nutzers in Ihrem Active Directory. Dadurch wird die Nutzerverwaltung vereinfacht und dafür gesorgt, dass Berechtigungen synchronisiert werden. 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).

Workflow für die Integration in Active Directory

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 für den Nutzer keine entsprechende PostgreSQL-Rolle vorhanden ist, wird sie automatisch vom System erstellt, z. B. CREATE ROLE "user@REALM" WITH LOGIN;.
LDAP-Gruppenprüfung: Das System stellt über LDAP eine sichere Verbindung zu Ihrem Active Directory her, um die aktuellen Gruppenzugehörigkeiten des Nutzers abzurufen.
Mitgliedschaftssynchronisierung: Das System vergleicht die Active Directory-Gruppen des Nutzers mit den von Ihnen konfigurierten Zuordnungen.
- Wenn der Nutzer in einer zugeordneten Active Directory-Gruppe, aber nicht in der entsprechenden PostgreSQL-Gruppe ist, wird ihm die Mitgliedschaft gewährt.
- Wenn der Nutzer nicht in einer zugeordneten Active Directory-Gruppe, aber in der entsprechenden PostgreSQL-Gruppe ist, wird die Mitgliedschaft des Nutzers widerrufen.
Anmeldung abgeschlossen: Die Verbindung des Nutzers ist 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 synchronisiert.

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

Hinweise

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

GSSAPI-Authentifizierung: Sie müssen die GSSAPI-basierte Authentifizierung für Ihre AlloyDB Omni-Instanz konfiguriert haben. 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, diesen PostgreSQL-Gruppenrollen manuell zuweisen. Die Integration verwaltet nur die Mitgliedschaft, nicht aber 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 von Active Directory-Gruppen konfigurieren möchten, müssen Sie eine UserDefinedAuthentication-Benutzerressource auf Ihren vorhandenen Datenbankcluster anwenden.

Konfigurieren Sie AlloyDB Omni mit den Anmeldedaten des LDAP-Servers. Wenden Sie das folgende benutzerdefinierte Authentifizierungsmanifest für benutzerdefinierte Ressourcen 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

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: LDAP-Server-URI, z. B. ldaps://ad.example.com:636.
LDAP_BASE_DN: Base-DN für LDAP-Suchvorgänge. z.B. DC=ad,DC=alloydb,DC=COM
LDAP_BIND_DN: Distinguished Name (DN) für den LDAP-Bind-Nutzer.
LDAP_PASSWORD_SECRET_REF: Verweis auf das Kubernetes-Secret mit dem LDAP-Passwort. Der Schlüssel dieses Secrets muss password sein.
LDAPS_CERT_SECRET_REF: (Optional) Verweis auf das Kubernetes-Secret mit dem LDAPS-Zertifikat. Der Schlüssel dieses Secrets muss ldap.crt sein.
CACHE_TTL_SECONDS: (Optional) Maximale Wartezeit in Sekunden, bevor eine Synchronisierung der LDAP-Gruppenmitgliedschaft ausgelöst wird. Der Standardwert ist 3.600 Sekunden.
LDAP_CONNECTION_TIMEOUT: (Optional) Zeitüberschreitung für die LDAP-Verbindung in Millisekunden. Der Standardwert ist 5.000 ms.

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

Verbindung zu AlloyDB Omni herstellen, das auf 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

Wenn Sie eine Active Directory-Gruppe einer PostgreSQL-Gruppenrolle zuordnen möchten, die Sie bereits erstellt haben, verwenden Sie die Funktion map_ad_group().

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

Wenn Sie eine vorhandene Zuordnung entfernen möchten, verwenden Sie die Funktion unmap_ad_group(). 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

Wenn Sie einen einzelnen Active Directory-Nutzer einer PostgreSQL-Rolle zuordnen möchten, die Sie bereits erstellt haben, verwenden Sie die Funktion map_ad_user().

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 in dem Client aktiviert sein, mit dem Sie eine Verbindung herstellen.

Im folgenden Beispiel sind auf dem postgres-client-Pod kinit und psql installiert. Er ist so konfiguriert, dass er über den psql-Client eine Verbindung zum AlloyDB Omni-Cluster herstellt.

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 auf die AlloyDB Omni-Datenbank wird automatisch anhand der folgenden Kriterien 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 zum ersten Mal eine Verbindung herstellen, 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 Teil einer Active Directory-Gruppe mit dem Namen ad_developers. Der Administrator hat ad_developers einer Postgres-Rolle mit dem Namen 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: Diese Funktion automatisiert nur die Mitgliedschaft von Nutzern in vorhandenen PostgreSQL-Gruppen. Das Erstellen dieser Gruppen und das Gewähren ihrer Berechtigungen ist eine manuelle Verwaltungsaufgabe.
Synchronisierungslatenz: Die Mitgliedschaft wird erst synchronisiert, wenn sich ein Nutzer anmeldet. Änderungen an der Gruppenmitgliedschaft eines Nutzers in Active Directory werden erst bei der nächsten Anmeldung des Nutzers in AlloyDB Omni übernommen.
Leistung: Die LDAP-Suche führt zu einer geringen Latenz beim ersten Anmeldevorgang des Nutzers. Durch das Caching wird diese Latenz für nachfolgende Anmeldungen innerhalb der konfigurierten Gültigkeitsdauer (auth_cache_ttl_sec) reduziert.
Fehlerbehandlung: 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.