Se usó la API de Cloud Translation para traducir esta página.

Integra la compatibilidad con usuarios de Active Directory en Kubernetes

Selecciona una versión de la documentación:

En este documento, se describe cómo habilitar la integración de Active Directory en tu clúster de base de datos de AlloyDB Omni basado en Kubernetes para que puedas permitir que los usuarios existentes basados en Active Directory accedan a tu base de datos de AlloyDB Omni. La integración de Active Directory proporciona autorización con GSSAPI para que los usuarios autenticados con el mecanismo de Kerberos accedan a AlloyDB Omni.

Para obtener más información, consulta Descripción general de Active Directory.

En este documento, se supone que estás familiarizado con la aplicación de archivos de manifiesto de Kubernetes y el uso de la herramienta de línea de comandos de kubectl. Para obtener más información, consulta Herramienta de línea de comandos (kubectl).

Antes de comenzar

Para habilitar la integración de Active Directory, debes cumplir con los siguientes requisitos:

Un clúster de AlloyDB Omni implementado en un entorno de Kubernetes
Un archivo keytab del servidor de Active Directory

Migra del operador de Kubernetes de AlloyDB Omni 1.4.0 a 1.5.0

Si usas la integración de Active Directory en el operador de AlloyDB Omni versión 1.4.0 o anterior, debes migrar al operador de AlloyDB Omni versión 1.5.0.

Para migrar a la versión 1.5.0 del operador de AlloyDB Omni, sigue estos pasos:

Actualiza el operador de AlloyDB Omni a la versión 1.5.0.
Crea un recurso de autenticación definido por el usuario.
1. Crea un manifiesto de recurso UserDefinedAuthentication nuevo.
2. Propaga spec.dbclusterRef con el nombre del DBCluster de destino.
3. Completa spec.keytabSecretRef con el nombre del Secret de keytab.
4. Copia las reglas pg_hba.conf existentes que sean pertinentes para la autenticación de Active Directory y Kerberos en el campo spec.pgHbaEntries.
5. Copia el pg_ident.conf rules existente (si hay alguno) en el campo spec.pgIdentEntries.
6. Aplica este nuevo manifiesto, por ejemplo, kubectl apply -f user-auth-crd.yaml.
Quita la configuración de vista previa y vuelve a implementar el clúster.
1. En la definición del recurso DBCluster, quita todas las anotaciones que usaste anteriormente para configurar la integración de Active Directory, por ejemplo, las reglas de autenticación basadas en host (HBA), las reglas de ident y la anotación del archivo keytab.
2. Borra los mapas de configuración pg_hba y pg_ident que creaste.
3. Vuelve a aplicar el manifiesto de DBCluster actualizado.

Configura la compatibilidad con Active Directory

Crea y aplica un secreto con el archivo keytab:
```
apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT
```
El siguiente es un ejemplo de un comando que genera un archivo keytab en el servidor de Active Directory:
```
ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH
```
ALLOYDB_HOST es el host que apunta a DBCluster o a la dirección IP de DBCluster.

Nota: Para obtener el archivo keytab codificado en base64, usa un comando como el siguiente: cat postgres.keytab | base64.
Aplica el siguiente manifiesto de recurso personalizado de autenticación definido por el usuario:
```
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
```
Reemplaza lo siguiente:
- USER_DEFINED_AUTHENTICATION_NAME: Es el nombre de UserDefinedConfiguration, por ejemplo, DB_CLUSTER_NAME-ad-auth.
- DB_CLUSTER_NAMESPACE: Es el espacio de nombres de Kubernetes para este plan de copia de seguridad. El espacio de nombres debe coincidir con el del clúster de la base de datos.
- DB_CLUSTER_NAME: Es el nombre del clúster de la base de datos que asignaste cuando lo creaste.
- KEYTAB_SECRET_NAME: Es el nombre del archivo keytab que creaste.
- PG_HBA_ENTRIES: Entradas de pg_hba.conf como una lista de cadenas. Estas entradas reemplazan las entradas predeterminadas en pg_hba.conf. Si agregas una configuración no válida, los usuarios no podrán acceder.
  
  En el ejemplo anterior, agregaste entradas para la autenticación basada en GSS y, luego, para la autenticación basada en contraseñas. Esto significa que el usuario accedió con la API de GSS. Si este enfoque de acceso falla, se usa la autenticación basada en contraseña como alternativa.
  
  Para obtener más información, consulta El archivo pg_hba.conf.
- PG_IDENT_ENTRIES: Entradas de pg_ident.conf como una lista de cadenas. Para implementar la asignación de nombres de usuario, especifica map= en el campo de opciones del archivo pg_hba.conf. Para obtener más información, consulta Ident Maps.
  
  Consulta el siguiente ejemplo:
```
 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
```

Crea roles de base de datos como usuario de Active Directory

Crea un rol en tu base de datos que coincida con el usuario de Active Directory. Para crear un rol para tu usuario de Active Directory, conéctate al clúster y ejecuta los siguientes comandos:
```
username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;
```

Accede a la base de datos con el usuario de Active Directory. Debes tener kinit habilitado en el cliente al que te conectas. En este ejemplo, el pod postgres-client tiene instalados kinit y psql, y está configurado para conectarse al clúster de AlloyDB Omni con el cliente psql.

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.

Ejecutar consultas en SQL
```
username=# select * from TABLE_NAME;
```

Inhabilita la autenticación de Active Directory

Para inhabilitar la autenticación de Active Directory, ejecuta el siguiente comando de Helm:

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

El comando muestra el siguiente resultado:

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