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

Intégrer Active Directory à AlloyDB Omni 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.

La configuration d'Active Directory dans AlloyDB Omni est facultative et désactivée par défaut. Seuls les environnements utilisant Active Directory Server pour l'authentification peuvent utiliser ce mécanisme de configuration.

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

Activer l'authentification Active Directory

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

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

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

Vérifier l'état de l'authentification Active Directory

Pour déterminer l'état de l'authentification Active Directory, procédez comme suit :

Obtenez le args de déploiement actuel pour le contrôleur de parc et assurez-vous que enable-user-defined-authentication est défini sur true. Pour ce faire, exécutez les commandes suivantes :

kubectl get deployment -n alloydb-omni-system fleet-controller-manager -o json | jq '.spec.template.spec.containers[0].args'

[
  "--health-probe-bind-address=:8081",
  "--metrics-bind-address=127.0.0.1:8080",
  "--leader-elect",
  "--image-registry=gcr.io",
  ...
  "--enable-user-defined-authentication=true"
]

Obtenez les arguments de déploiement actuels pour le contrôleur local et assurez-vous que enable-user-defined-authentication est défini sur true en exécutant les commandes suivantes :

kubectl get deployment -n alloydb-omni-system local-controller-manager -o json | jq '.spec.template.spec.containers[0].args'

[
  "--health-probe-bind-address=:8081",
  "--metrics-bind-address=127.0.0.1:8080",
  "--leader-elect",
  "--deployment-platform=generic-k8s",
  "--enable-backup-from-standby=true",
  "--enable-user-defined-authentication=true"
]

Configurer la compatibilité avec Active Directory

Créez et appliquez un ConfigMap à l'aide des entrées de fichier pg_hba.conf :
```
kubectl apply -f - 
apiVersion: v1
kind: ConfigMap
metadata:
  name: pg-hba-config
data:
  pg_hba_entries: |
    # Active Directory-based users
    hostgssenc all all 0.0.0.0/0    gss
    hostgssenc all all ::1/128      gss
    # Database-based users
    hostssl    all all 0.0.0.0/0  scram-sha-256
    hostssl    all all ::/0       scram-sha-256
EOF
```
Modifiez ces entrées en fonction de vos besoins. Ces entrées écrasent les entrées par défaut dans pg_hba.conf. Si vous ajoutez une configuration non valide, les utilisateurs ne pourront 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 par mot de passe. Cela signifie que l'utilisateur sera connecté à l'aide de l'API GSS. Si cette approche de connexion échoue, l'authentification par mot de passe sera utilisée comme solution de secours.

Pour en savoir plus, consultez le fichier pg_hba.conf.

Créez et appliquez un secret avec le keytab :

 kubectl apply -f - 
 apiVersion: v1
 kind: Secret
 metadata:
   name: db-keytab-dbcluster-sample
 type: Opaque
 data:
   krb5.keytab: |
    BASE64_ENCODED_KEYTAB
 EOF

Facultatif : Créez et appliquez un ConfigMap à l'aide d'entrées pg_ident.conf.

  kubectl apply -f - EOF
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: pg-ident-config
  data:
    pg_ident_entries: |

      MAP_NAME /^(.)@YOUR.REALM$/        \1
      MAP_NAME /^(.)@your.realm$/        \1
  EOF

Pour implémenter le mappage des noms d'utilisateur, spécifiez map=MAP_NAME dans le champ des options du fichier pg_hba.conf.

Pour en savoir plus, consultez Ident Maps.

Pour activer l'intégration à Active Directory, ajoutez des annotations à la spécification DBCluster.

kubectl apply -f - DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  annotations:
    dbs.dbadmin.goog.com/pg-hba-config-map: pg-hba-config
    dbs.dbadmin.goog.com/pg-ident-config-map: pg-ident-config
    dbs.dbadmin.goog.com/keytab-ref: db-keytab-dbcluster-sample
spec:
  databaseVersion: "DB_VERSION"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      memory: MEMORY_SIZE
      cpu: CPU_COUNT
      disks:
      - name: DataDisk
        size: DISK_SIZE
EOF

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.

kubectl exec -it postgres -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 ;
```

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

Vous pouvez vérifier l'état de l'authentification Active Directory.