En esta página, se documenta la versión 16.9.0 de AlloyDB Omni con la opción de implementación de Kubernetes. Elige otra opción de implementación.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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 tus usuarios existentes basados en Active Directory accedan a tu base de datos de AlloyDB Omni. La integración de Active Directory proporciona autorización mediante GSSAPI para los usuarios autenticados con el mecanismo Kerberos para acceder a AlloyDB Omni.

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

En este documento, se da por sentado 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 tener lo siguiente:

Un clúster de AlloyDB Omni implementado en un entorno de Kubernetes
Un 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 al operador de AlloyDB Omni versión 1.5.0, 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. Propaga spec.keytabSecretRef con el nombre del secreto de keytab.
4. Copia las reglas pg_hba.conf existentes que sean relevantes para la autenticación de Active Directory y Kerberos en el campo spec.pgHbaEntries.
5. Copia los pg_ident.conf rules existentes (si los hay) en el campo spec.pgIdentEntries.
6. Aplica este manifiesto nuevo, 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 de 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 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 comando de ejemplo que genera un 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 al DBCluster o a la dirección IP del DBCluster.

Nota: Para obtener el 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: El nombre de la UserDefinedConfiguration, por ejemplo, DB_CLUSTER_NAME-ad-auth.
- DB_CLUSTER_NAMESPACE: El espacio de nombres de Kubernetes para este plan de copia de seguridad. El espacio de nombres debe coincidir con el espacio de nombres del clúster de base de datos.
- DB_CLUSTER_NAME: El nombre de tu clúster de base de datos, que asignaste cuando lo creaste.
- KEYTAB_SECRET_NAME: El nombre del keytab que creaste.
- PG_HBA_ENTRIES: Entradas 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 seguida de la autenticación basada en contraseña. Esto significa que el usuario accede con la API de GSS. Si este enfoque de acceso falla, entonces 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 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 Mapas de ident.
  
  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 instalado 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.

Ejecuta 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 devuelve 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