Questa pagina documenta la versione 16.8.0 di AlloyDB Omni utilizzando l'opzione di deployment Kubernetes. Scegli un'altra opzione di implementazione.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Integra il supporto dei gruppi Active Directory su Kubernetes

Seleziona una versione della documentazione:

Anteprima : AlloyDB Omni

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Puoi accedere ai dati personali per questa funzionalità come indicato nell' Addendum per il trattamento dei dati Cloud, fatti salvi gli obblighi e le restrizioni all'interno dell' accordo che regola l'accesso a Google Cloud. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Questa pagina descrive come configurare e gestire l'autenticazione e l'autorizzazione basate su gruppi di Active Directory in AlloyDB Omni di cui è stato eseguito il deployment su Kubernetes. Il supporto basato su gruppi di Active Directory automatizza la gestione delle appartenenze ai ruoli PostgreSQL in base alle appartenenze ai gruppi di un utente in Active Directory, il che semplifica la gestione degli utenti e garantisce che le autorizzazioni siano sincronizzate. Per ulteriori informazioni, consulta la panoramica di Active Directory.

Questo documento presuppone che tu abbia familiarità con l'applicazione dei file manifest di Kubernetes e con l'utilizzo dello strumento a riga di comando kubectl. Per ulteriori informazioni, consulta Strumento a riga di comando (kubectl).

Workflow di integrazione di Active Directory

L'integrazione di Active Directory viene implementata utilizzando un'estensione PostgreSQL (google_pg_auth) nel seguente workflow:

Accesso utente: un utente esegue l'autenticazione ad AlloyDB Omni utilizzando le credenziali standard di Active Directory tramite l'interfaccia di programmazione dell'applicazione Generic Security Services (GSSAPI).
Creazione automatica dei ruoli: se non esiste un ruolo PostgreSQL corrispondente per l'utente il sistema ne crea automaticamente uno, ad esempio CREATE ROLE "user@REALM" WITH LOGIN;.
Controllo dei gruppi LDAP: il sistema si connette in modo sicuro ad Active Directory utilizzando LDAP per recuperare le appartenenze ai gruppi correnti dell'utente.
Sincronizzazione dell'appartenenza: il sistema confronta i gruppi di Active Directory dell'utente con le mappature configurate.
- Se l'utente appartiene a un gruppo di Active Directory mappato, ma non al gruppo PostgreSQL corrispondente, gli viene concessa l'appartenenza.
- Se l'utente non appartiene a un gruppo di Active Directory mappato, ma al gruppo PostgreSQL corrispondente, l'appartenenza dell'utente viene revocata.
Accesso completato: la connessione dell'utente viene finalizzata e l'utente accede al database. Le autorizzazioni dell'utente sono determinate dai ruoli PostgreSQL a cui appartiene, che sono sincronizzati con lo stato del gruppo di Active Directory.

Questa sincronizzazione avviene automaticamente a ogni accesso dell'utente, il che garantisce che i diritti di accesso a PostgreSQL riflettano lo stato attuale di Active Directory.

Prima di iniziare

Prima di integrare il supporto dei gruppi di Active Directory con AlloyDB Omni, assicurati di soddisfare i seguenti requisiti.

Autenticazione GSSAPI: devi aver configurato e reso operativo l'autenticazione basata su GSSAPI per l'istanza AlloyDB Omni. Per ulteriori informazioni, consulta Integrare Active Directory con AlloyDB Omni.
Ruoli di gruppo PostgreSQL: devi creare manualmente i ruoli di gruppo PostgreSQL che intendi mappare ai gruppi di Active Directory, come mostrato nell'esempio seguente:
```
CREATE ROLE "postgres_developers";
CREATE ROLE "postgres_read_only";
```
Autorizzazioni: devi assegnare manualmente le autorizzazioni del database, ad esempio SELECT e INSERT, a questi ruoli di gruppo PostgreSQL. L'integrazione gestisce solo l'appartenenza, ma non i privilegi dei gruppi stessi, come mostrato nell'esempio seguente:
```
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;
```

Configurare il supporto dei gruppi di Active Directory

Per configurare il supporto dei gruppi di Active Directory, devi applicare una risorsa personalizzata UserDefinedAuthentication al cluster di database esistente.

Configura AlloyDB Omni utilizzando le credenziali del server LDAP. Applica il seguente manifest della risorsa personalizzata di autenticazione definita dall'utente:

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

Assicurati di sostituire quanto segue:

USER_DEFINED_AUTHENTICATION_NAME: il nome di UserDefinedConfiguration, ad esempio DB_CLUSTER_NAME-ad-auth.
DB_CLUSTER_NAMESPACE: lo spazio dei nomi Kubernetes per questo piano di backup. Lo spazio dei nomi deve corrispondere allo spazio dei nomi del cluster di database.
DB_CLUSTER_NAME: il nome del cluster di database, che hai assegnato quando l'hai creato.
LDAP_URI: URI del server LDAP, ad esempio ldaps://ad.example.com:636.
LDAP_BASE_DN: DN di base per le ricerche LDAP. (ad es. DC=ad,DC=alloydb,DC=COM)
LDAP_BIND_DN: nome distinto (DN) per l'utente di binding LDAP.
LDAP_PASSWORD_SECRET_REF: riferimento al secret Kubernetes con la password LDAP. La chiave di questo secret deve essere password.
LDAPS_CERT_SECRET_REF: (facoltativo) riferimento al secret Kubernetes con il certificato LDAPS. La chiave di questo secret deve essere ldap.crt.
CACHE_TTL_SECONDS: (facoltativo) tempo massimo di attesa prima di attivare una sincronizzazione dell'appartenenza ai gruppi LDAP in secondi. Il valore predefinito è 3600 secondi.
LDAP_CONNECTION_TIMEOUT: (facoltativo) timeout della connessione LDAP in millisecondi. Il valore predefinito è 5000 ms.

Vedi il seguente esempio:

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

Gestire le mappature dei gruppi

Puoi creare e gestire le mappature tra i gruppi di Active Directory e i ruoli PostgreSQL utilizzando le funzioni SQL.

Accedere al cluster e caricare l'estensione

Connettiti ad AlloyDB Omni in esecuzione su Kubernetes.

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

Creare una mappatura dei gruppi

Per mappare un gruppo di Active Directory a un ruolo di gruppo PostgreSQL che hai già creato, utilizza la funzione map_ad_group().

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

Nell'esempio seguente, il gruppo di Active Directory ad-developers viene mappato al ruolo PostgreSQL pg-developers:

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

Per recuperare il SID di un gruppo specifico in Active Directory, utilizza il seguente comando sul server Active Directory:

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

Rimuovere una mappatura dei gruppi

Per rimuovere una mappatura esistente, utilizza la funzione unmap_ad_group(), che interrompe la sincronizzazione per quel gruppo. La funzione unmap_ad_group() non rimuove gli utenti dal gruppo PostgreSQL se sono già membri.

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

Vedi il seguente esempio:

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

Creare una mappatura degli utenti

Per mappare un singolo utente di Active Directory a un ruolo PostgreSQL che hai già creato, utilizza la funzione map_ad_user().

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

Ad esempio, per mappare l'utente di Active Directory quinn@google.com al ruolo PostgreSQL pg-developers, procedi nel seguente modo:

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

Rimuovere una mappatura degli utenti

Per rimuovere una mappatura esistente, utilizza la funzione unmap_ad_user().

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

Ad esempio, per annullare la mappatura dell'utente di Active Directory quinn@google.com dal ruolo PostgreSQL pg-developers, procedi nel seguente modo:

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

Connettersi al database AlloyDB Omni

Accedi al database AlloyDB Omni utilizzando l'utente di Active Directory. Devi aver abilitato kinit nel client a cui ti stai connettendo.

Nell'esempio seguente, il pod postgres-client ha kinit e psql installati ed è configurato per connettersi al cluster AlloyDB Omni utilizzando il client psql.

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=#

Il tuo accesso al database AlloyDB Omni viene determinato automaticamente in base a:

La tua appartenenza attuale ai gruppi di Active Directory.
Le mappature definite dall'amministratore tra questi gruppi di Active Directory e i ruoli PostgreSQL.
Le autorizzazioni concesse dall'amministratore a questi ruoli PostgreSQL.

Se è la prima volta che ti connetti, il tuo ruolo utente PostgreSQL (your_ad_user@YOURDOMAIN.COM) viene creato automaticamente.

Ogni volta che accedi, il sistema controlla le appartenenze ai gruppi di Active Directory correnti e aggiorna le appartenenze ai ruoli PostgreSQL corrispondenti in modo che corrispondano. Non è necessario intraprendere alcuna azione specifica per la sincronizzazione.

Esempio di connessione al database

Nell'esempio seguente, un utente Quinn fa parte di un gruppo di Active Directory denominato ad_developers. L'amministratore ha mappato ad_developers a un ruolo postgres denominato postgres_read_only. Questo ruolo ha accesso in lettura a una tabella denominata sales. Quando l'utente accede, può accedere alla tabella.

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

Nell'esempio seguente, Quinn viene rimosso dal gruppo ad_developers in Active Directory.

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

Limitazioni

Gestione manuale di gruppi e autorizzazioni: questa funzionalità automatizza solo l'appartenenza degli utenti ai gruppi PostgreSQL esistenti. La creazione di questi gruppi e la concessione delle relative autorizzazioni sono attività amministrative manuali.
Latenza di sincronizzazione: l'appartenenza viene sincronizzata solo quando un utente accede. Le modifiche apportate all'appartenenza ai gruppi di un utente in Active Directory vengono applicate ad AlloyDB Omni solo alla sessione di accesso successiva dell'utente.
Prestazioni: la ricerca LDAP aggiunge una piccola quantità di latenza al processo di accesso iniziale dell'utente. La memorizzazione nella cache contribuisce a ridurre questa latenza per gli accessi successivi entro il tempo di attività configurato (auth_cache_ttl_sec).
Gestione degli errori: se il server LDAP non è raggiungibile o se si verificano altri errori durante il processo di sincronizzazione, AlloyDB Omni registra l'errore. Tuttavia, l'accesso dell'utente avrà esito positivo perché l'autenticazione GSSAPI è riuscita. Solo la sincronizzazione dell'iscrizione al gruppo per quella sessione non andrà a buon fine.