Intégrer la compatibilité avec les groupes Active Directory sur Kubernetes

Sélectionnez une version de la documentation :

Cette page explique comment configurer et gérer l'authentification et l'autorisation basées sur les groupes Active Directory dans AlloyDB Omni déployé sur Kubernetes. L'assistance basée sur les groupes Active Directory automatise la gestion des appartenances aux rôles PostgreSQL en fonction des appartenances aux groupes d'un utilisateur dans votre Active Directory. Cela simplifie la gestion des utilisateurs et garantit la synchronisation des autorisations. Pour en savoir plus, consultez Présentation d'Active Directory.

Dans ce document, nous partons du principe que vous savez appliquer des fichiers manifestes Kubernetes et utiliser l'outil de ligne de commande kubectl. Pour en savoir plus, consultez Outil de ligne de commande (kubectl).

Workflow d'intégration Active Directory

L'intégration d'Active Directory est implémentée à l'aide d'une extension PostgreSQL (google_pg_auth) dans le workflow suivant :

  1. Connexion de l'utilisateur : un utilisateur s'authentifie auprès d'AlloyDB Omni à l'aide de ses identifiants Active Directory standards à l'aide de l'interface de programmation d'application Generic Security Services (GSSAPI).
  2. Création automatique de rôles : si aucun rôle PostgreSQL correspondant à l'utilisateur n'existe, le système en crée automatiquement un (par exemple, CREATE ROLE "user@REALM" WITH LOGIN;).
  3. Vérification des groupes LDAP : le système se connecte de manière sécurisée à votre Active Directory à l'aide du protocole LDAP pour récupérer les appartenances actuelles de l'utilisateur à des groupes.

  4. Synchronisation des membres : le système compare les groupes Active Directory de l'utilisateur aux mappages que vous avez configurés.

    • Si l'utilisateur appartient à un groupe Active Directory mappé, mais pas au groupe PostgreSQL correspondant, il est ajouté au groupe.
    • Si l'utilisateur n'appartient pas à un groupe Active Directory mappé, mais qu'il appartient au groupe PostgreSQL correspondant, son appartenance est révoquée.

  5. Connexion terminée : la connexion de l'utilisateur est finalisée et il est connecté à la base de données. Les autorisations de l'utilisateur sont déterminées par les rôles PostgreSQL auxquels il appartient, qui sont synchronisés avec l'état de son groupe Active Directory.

    Cette synchronisation s'effectue automatiquement à chaque connexion d'un utilisateur, ce qui garantit que les droits d'accès PostgreSQL reflètent l'état actuel de votre Active Directory.

Avant de commencer

Avant d'intégrer la compatibilité avec les groupes Active Directory à AlloyDB Omni, assurez-vous de remplir les conditions suivantes.

  • Authentification GSSAPI : vous devez avoir configuré et rendu opérationnelle l'authentification basée sur GSSAPI pour votre instance AlloyDB Omni. Pour en savoir plus, consultez Intégrer Active Directory à AlloyDB Omni.

  • Rôles de groupe PostgreSQL : vous devez créer manuellement les rôles de groupe PostgreSQL que vous souhaitez mapper aux groupes Active Directory, comme indiqué dans l'exemple suivant :

    CREATE ROLE "postgres_developers";
CREATE ROLE "postgres_read_only";

  • Autorisations : vous devez attribuer manuellement les autorisations de base de données (par exemple, SELECT et INSERT) à ces rôles de groupe PostgreSQL. L'intégration ne gère que les membres, mais pas les droits d'accès des groupes eux-mêmes, comme illustré dans l'exemple suivant :

    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;

Configurer la compatibilité avec les groupes Active Directory

Pour configurer la compatibilité avec les groupes Active Directory, vous devez appliquer une ressource personnalisée UserDefinedAuthentication à votre cluster de bases de données existant.

  1. Configurez AlloyDB Omni à l'aide des identifiants du serveur LDAP. Appliquez le fichier manifeste de ressource personnalisée d'authentification définie par l'utilisateur suivant :

    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

    Effectuez les remplacements suivants :

    • USER_DEFINED_AUTHENTICATION_NAME : nom de UserDefinedConfiguration, par exemple DB_CLUSTER_NAME-ad-auth.
    • DB_CLUSTER_NAMESPACE : espace de noms Kubernetes pour ce plan de sauvegarde. L'espace de noms doit correspondre à celui du cluster de bases de données.
    • DB_CLUSTER_NAME : nom du cluster de base de données que vous avez attribué lors de sa création.
    • LDAP_URI : URI du serveur LDAP, par exemple ldaps://ad.example.com:636.
    • LDAP_BASE_DN : DN de base pour les recherches LDAP. (par exemple, DC=ad,DC=alloydb,DC=COM)
    • LDAP_BIND_DN : nom distinctif (DN) de l'utilisateur LDAP pour l'association.
    • LDAP_PASSWORD_SECRET_REF : référence au secret Kubernetes contenant le mot de passe LDAP. La clé de ce secret doit être password.
    • LDAPS_CERT_SECRET_REF : (facultatif) référence au secret Kubernetes avec le certificat LDAPS. La clé de ce secret doit être ldap.crt.
    • CACHE_TTL_SECONDS : (facultatif) délai d'attente maximal avant le déclenchement d'une synchronisation de l'appartenance à un groupe LDAP, en secondes. La valeur par défaut est de 3 600 secondes.
    • LDAP_CONNECTION_TIMEOUT : (facultatif) délai d'expiration de la connexion LDAP en millisecondes. La valeur par défaut est de 5 000 ms.

    Consultez l'exemple ci-dessous :

    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

Gérer les mappages de groupes

Vous pouvez créer et gérer des mappages entre des groupes Active Directory et des rôles PostgreSQL à l'aide de fonctions SQL.

Se connecter au cluster et charger l'extension

  • Se connecter à AlloyDB Omni exécuté sur 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

Créer un mappage de groupe

Pour mapper un groupe Active Directory à un rôle de groupe PostgreSQL que vous avez déjà créé, utilisez la fonction map_ad_group().

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

Dans l'exemple suivant, le groupe Active Directory ad-developers est mappé au rôle PostgreSQL pg-developers :

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

Pour récupérer le SID d'un groupe spécifique dans Active Directory, utilisez la commande suivante sur votre serveur Active Directory :

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

Supprimer un mappage de groupe

Pour supprimer un mappage existant, utilisez la fonction unmap_ad_group(), qui arrête la synchronisation pour ce groupe. La fonction unmap_ad_group() ne supprime pas les utilisateurs du groupe PostgreSQL s'ils en sont déjà membres.

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

Consultez l'exemple ci-dessous :

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

Créer un mappage d'utilisateurs

Pour mapper un utilisateur Active Directory individuel à un rôle PostgreSQL que vous avez déjà créé, utilisez la fonction map_ad_user().

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

Par exemple, pour mapper l'utilisateur Active Directory quinn@google.com au rôle PostgreSQL pg-developers, procédez comme suit :

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

Supprimer un mappage utilisateur

Pour supprimer un mappage existant, utilisez la fonction unmap_ad_user().

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

Par exemple, pour dissocier l'utilisateur Active Directory quinn@google.com du rôle PostgreSQL pg-developers, procédez comme suit :

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

Se connecter à la base de données AlloyDB Omni

Connectez-vous à la base de données AlloyDB Omni à l'aide de l'utilisateur Active Directory. Vous devez avoir activé kinit dans le client auquel vous vous connectez.

Dans l'exemple suivant, le pod postgres-client a installé kinit et psql et est configuré pour se connecter au cluster AlloyDB Omni à l'aide du 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=#

Votre accès à la base de données AlloyDB Omni est déterminé automatiquement en fonction des éléments suivants :

  • Votre appartenance actuelle à des groupes Active Directory.
  • Les mappages définis par l'administrateur entre ces groupes Active Directory et les rôles PostgreSQL.
  • Les autorisations accordées par l'administrateur à ces rôles PostgreSQL.

Si vous vous connectez pour la première fois, votre rôle d'utilisateur PostgreSQL (your_ad_user@YOURDOMAIN.COM) est créé automatiquement.

Chaque fois que vous vous connectez, le système vérifie vos appartenances actuelles aux groupes Active Directory et met à jour vos appartenances aux rôles PostgreSQL correspondants. Aucune action spécifique de votre part n'est requise pour que cette synchronisation ait lieu.

Exemple de connexion à une base de données

Dans l'exemple suivant, l'utilisateur Quinn fait partie d'un groupe Active Directory nommé ad_developers. L'administrateur a mappé ad_developers à un rôle postgres nommé postgres_read_only. Ce rôle dispose d'un accès en lecture à une table nommée sales. Lorsque l'utilisateur se connecte, il peut accéder à la table.

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

Dans l'exemple suivant, Quinn est supprimé du groupe ad_developers dans 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

Limites

  • Gestion manuelle des groupes et des autorisations : cette fonctionnalité automatise uniquement l'appartenance des utilisateurs aux groupes PostgreSQL existants. La création de ces groupes et l'attribution de leurs autorisations sont des tâches administratives manuelles.
  • Latence de synchronisation : l'abonnement n'est synchronisé que lorsqu'un utilisateur se connecte. Toute modification apportée à l'appartenance d'un utilisateur à un groupe dans Active Directory n'est reflétée dans AlloyDB Omni qu'à la prochaine session de connexion de l'utilisateur.
  • Performances : la recherche LDAP ajoute un peu de latence au processus de connexion initial de l'utilisateur. La mise en cache permet d'atténuer cette latence pour les connexions ultérieures dans la durée de vie configurée (auth_cache_ttl_sec).
  • Gestion des erreurs : si le serveur LDAP est inaccessible ou si d'autres erreurs se produisent lors du processus de synchronisation, AlloyDB Omni consigne l'erreur. Toutefois, la connexion de l'utilisateur aboutira quand même, car l'authentification GSSAPI a réussi. Seule la synchronisation de l'appartenance au groupe pour cette session échouera.

Étapes suivantes