Cette page a été traduite par l'API Cloud Translation.

Intégrer l'assistance aux utilisateurs Active Directory sur Kubernetes

Sélectionnez une version de la documentation :

Ce document explique comment activer l'intégration Active Directory sur votre cluster de base de données AlloyDB Omni basé sur Kubernetes afin de permettre à vos utilisateurs existants basés sur Active Directory d'accéder à votre base de données AlloyDB Omni. L'intégration d'Active Directory fournit une autorisation à l'aide de GSSAPI pour les utilisateurs authentifiés à l'aide du mécanisme Kerberos afin d'accéder à AlloyDB Omni.

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

Avant de commencer

Pour activer l'intégration à Active Directory, vous devez disposer des éléments suivants :

Un cluster AlloyDB Omni déployé dans un environnement Kubernetes
Un keytab de serveur Active Directory

Migrer de l'opérateur Kubernetes AlloyDB Omni 1.4.0 vers la version 1.5.0

Si vous utilisez l'intégration Active Directory dans l'opérateur AlloyDB Omni version 1.4.0 ou antérieure, vous devez migrer vers l'opérateur AlloyDB Omni version 1.5.0.

Pour migrer vers la version 1.5.0 de l'opérateur AlloyDB Omni, procédez comme suit :

Mettez à niveau l'opérateur AlloyDB Omni vers la version 1.5.0.
Créez une ressource d'authentification définie par l'utilisateur.
1. Créez un fichier manifeste de ressource UserDefinedAuthentication.
2. Renseignez spec.dbclusterRef avec le nom du DBCluster cible.
3. Renseignez spec.keytabSecretRef avec le nom du secret keytab.
4. Copiez les règles pg_hba.conf existantes qui concernent l'authentification Active Directory et Kerberos dans le champ spec.pgHbaEntries.
5. Copiez le pg_ident.conf rules existant (le cas échéant) dans le champ spec.pgIdentEntries.
6. Appliquez ce nouveau fichier manifeste, par exemple kubectl apply -f user-auth-crd.yaml.
Supprimez la configuration de l'aperçu et redéployez le cluster.
1. Dans la définition de ressource DBCluster, supprimez toutes les annotations que vous avez utilisées précédemment pour configurer l'intégration Active Directory, par exemple les règles d'authentification basée sur l'hôte (HBA), les règles ident et l'annotation de fichier keytab.
2. Supprimez les ConfigMaps pg_hba et pg_ident que vous avez créés.
3. Appliquez à nouveau le fichier manifeste DBCluster mis à jour.

Configurer la compatibilité avec Active Directory

Créez et appliquez un secret avec le keytab :
```
apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT
```
Voici un exemple de commande qui génère un fichier keytab sur le serveur Active Directory :
```
ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH
```
ALLOYDB_HOST est l'hôte qui pointe vers le DBCluster ou l'adresse IP du DBCluster.

Remarque : Pour obtenir le fichier keytab encodé en base64, utilisez une commande comme la suivante : cat postgres.keytab | base64.
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
```
Remplacez les éléments 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 de votre cluster de bases de données, que vous avez attribué lors de sa création.
- KEYTAB_SECRET_NAME : nom du keytab que vous avez créé.
- PG_HBA_ENTRIES : entrées pg_hba.conf sous forme de liste de chaînes. Ces entrées écrasent les entrées par défaut dans pg_hba.conf. Si vous ajoutez une configuration non valide, les utilisateurs ne peuvent pas se connecter.
  
  Dans l'exemple précédent, vous avez ajouté des entrées pour l'authentification basée sur GSS, suivies de l'authentification basée sur un mot de passe. Cela signifie que l'utilisateur est connecté à l'aide de l'API GSS. Si cette approche de connexion échoue, l'authentification par mot de passe est utilisée comme solution de secours.
  
  Pour en savoir plus, consultez le fichier pg_hba.conf.
- PG_IDENT_ENTRIES : entrées pg_ident.conf sous forme de liste de chaînes. Pour implémenter le mappage des noms d'utilisateur, spécifiez map= dans le champ des options du fichier pg_hba.conf. Pour en savoir plus, consultez Ident Maps.
  
  Consultez l'exemple ci-dessous :
```
 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
   pgIdentEntries:
     - usermap  active_directory_user postgres_user
```

Créer des rôles de base de données en tant qu'utilisateur Active Directory

Créez un rôle dans votre base de données qui correspond à l'utilisateur Active Directory. Pour créer un rôle pour votre utilisateur Active Directory, connectez-vous au cluster et exécutez les commandes suivantes :
```
username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;
```
Connectez-vous à la base de données à l'aide de l'utilisateur Active Directory. Vous devez avoir activé kinit dans le client auquel vous vous connectez. Dans cet exemple, le pod postgres-client est configuré pour se connecter au cluster AlloyDB Omni à l'aide du client psql, et les outils kinit et psql y sont installés.
```
kubectl exec -it postgres-client -n DB_CLUSTER_NAMESPACE -- bash
root:/# kinit USERNAME
Password for USERNAME@REALM:

root:/# psql -h HOSTNAME -d DB_NAME -U USERNAME@REALM
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.
```
Exécutez des requêtes SQL.
```
username=# select * from TABLE_NAME;
```

Désactiver l'authentification Active Directory

Pour désactiver l'authentification Active Directory, exécutez la commande Helm suivante :

helm upgrade alloydbomni-operator PATH_TO_CHART -n alloydb-omni-system --set userDefinedAuthentication.enabled=false

La commande renvoie le résultat suivant :

Release "alloydbomni-operator" has been upgraded. Happy Helming!
NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 2
TEST SUITE: None