Integra il supporto dei gruppi Active Directory su Kubernetes

Seleziona una versione della documentazione:

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 sui 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 la sincronizzazione delle autorizzazioni. Per ulteriori informazioni, vedi Panoramica di Active Directory.

Questo documento presuppone che tu abbia familiarità con l'applicazione dei file manifest Kubernetes e con l'utilizzo dello strumento a riga di comando kubectl. Per saperne di più, 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 flusso di lavoro:

  1. Accesso utente: un utente si autentica su AlloyDB Omni utilizzando le proprie credenziali Active Directory standard tramite l'interfaccia di programmazione dell'applicazione Generic Security Services (GSSAPI).
  2. 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;.
  3. Controllo dei gruppi LDAP: il sistema si connette in modo sicuro ad Active Directory utilizzando LDAP per recuperare le appartenenze ai gruppi attuali dell'utente.

  4. Sincronizzazione dell'appartenenza: il sistema confronta i gruppi Active Directory dell'utente con i mapping che hai configurato.

    • Se l'utente si trova in un gruppo Active Directory mappato, ma non nel gruppo PostgreSQL corrispondente, gli viene concessa l'appartenenza.
    • Se l'utente non fa parte di un gruppo Active Directory mappato, ma del gruppo PostgreSQL corrispondente, la sua appartenenza viene revocata.

  5. Accesso completato: la connessione dell'utente è finalizzata e l'utente ha eseguito l'accesso al database. Le autorizzazioni dell'utente sono determinate dai ruoli PostgreSQL a cui appartiene, che sono sincronizzati con lo stato del gruppo 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 Active Directory con AlloyDB Omni, assicurati di soddisfare i seguenti requisiti.

  • Autenticazione GSSAPI: devi aver configurato e reso operativa l'autenticazione basata su GSSAPI per l'istanza AlloyDB Omni. Per saperne di più, consulta Integrare Active Directory con AlloyDB Omni.

  • Ruoli di gruppo PostgreSQL: devi creare manualmente i ruoli di gruppo PostgreSQL che intendi mappare ai gruppi 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 Active Directory

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

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

    Effettua le seguenti sostituzioni:

    • 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 a quello del cluster di database.
    • DB_CLUSTER_NAME: il nome del cluster di database, che hai assegnato durante la creazione.
    • 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 segreto deve essere ldap.crt.
    • CACHE_TTL_SECONDS: (facoltativo) tempo massimo di attesa prima di attivare una sincronizzazione dell'appartenenza al gruppo 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 mappature tra i gruppi Active Directory e i ruoli PostgreSQL utilizzando le funzioni SQL.

Accedi al cluster e carica 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 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 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 un mapping utente

Per mappare un singolo utente 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 quinn@google.com di Active Directory al ruolo pg-developers di PostgreSQL, segui questi passaggi:

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

Rimuovere un mapping utente

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 il mapping dell'utente quinn@google.com Active Directory dal ruolo pg-developers PostgreSQL, procedi nel seguente modo:

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

Connettiti al database AlloyDB Omni

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

Nell'esempio seguente, il pod postgres-client ha installato kinit e psql 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 nel database AlloyDB Omni viene determinato automaticamente in base a quanto segue:

  • La tua attuale appartenenza ai gruppi Active Directory.
  • I mapping definiti dall'amministratore tra questi gruppi Active Directory e i ruoli PostgreSQL.
  • Le autorizzazioni concesse dall'amministratore a questi ruoli PostgreSQL.

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

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

Esempio di connessione al database

Nell'esempio seguente, l'utente Quinn fa parte di un gruppo 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 a gruppi PostgreSQL esistenti. La creazione di questi gruppi e la concessione delle relative autorizzazioni è un'attività amministrativa manuale.
  • Latenza di sincronizzazione: l'iscrizione viene sincronizzata solo quando un utente accede. Eventuali modifiche apportate all'appartenenza a un gruppo di un utente in Active Directory vengono riflesse in AlloyDB Omni solo alla successiva sessione di accesso dell'utente.
  • Rendimento: 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 la durata configurata (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à comunque esito positivo poiché l'autenticazione GSSAPI è riuscita. Solo la sincronizzazione dell'appartenenza al gruppo per quella sessione non andrà a buon fine.

Passaggi successivi