Integrar la asistencia para 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 AlloyDB Omni basado en Kubernetes para que puedas permitir que los usuarios de Active Directory accedan a tu base de datos AlloyDB Omni. La integración de Active Directory proporciona autorización mediante GSSAPI a los usuarios autenticados con el mecanismo Kerberos para acceder a AlloyDB Omni.

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

En este documento se da por hecho que sabes cómo aplicar archivos de manifiesto de Kubernetes y usar la herramienta de línea de comandos kubectl. Para obtener más información, consulta Herramienta de línea de comandos (kubectl).

Antes de empezar

Para habilitar la integración de Active Directory, debes tener lo siguiente:

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

Migrar del operador de AlloyDB Omni Kubernetes 1.4.0 a 1.5.0

Si utilizas 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 AlloyDB Omni, sigue estos pasos:

  1. Actualiza el operador de AlloyDB Omni a la versión 1.5.0.
  2. Crea un recurso de autenticación definido por el usuario.
    1. Crea un manifiesto de recursos UserDefinedAuthentication.
    2. Rellena spec.dbclusterRef con el nombre de DBCluster de destino.
    3. Rellena spec.keytabSecretRef con el nombre del secreto de keytab.
    4. Copia las reglas de pg_hba.conf que sean relevantes para la autenticación de Active Directory y Kerberos en el campo spec.pgHbaEntries.
    5. Copia el pg_ident.conf rules (si lo hay) en el campo spec.pgIdentEntries.
    6. Aplica este nuevo manifiesto, por ejemplo, kubectl apply -f user-auth-crd.yaml.
  3. Elimina la configuración de vista previa y vuelve a implementar el clúster.
    1. En la definición del recurso DBCluster, elimina todas las anotaciones que hayas usado anteriormente para configurar la integración de Active Directory, como las reglas de autenticación basada en host (HBA), las reglas de identidad y la anotación del archivo keytab.
    2. Elimina los mapas de configuración pg_hba y pg_ident que has creado.
    3. Vuelve a aplicar el archivo de manifiesto de DBCluster actualizado.

Configurar la compatibilidad con Active Directory

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

    A continuación, se muestra un ejemplo de 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.

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

    Haz los cambios siguientes:

    • USER_DEFINED_AUTHENTICATION_NAME: el nombre de UserDefinedConfiguration. Por ejemplo, DB_CLUSTER_NAME-ad-auth.
    • DB_CLUSTER_NAMESPACE: el espacio de nombres de Kubernetes de 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: el nombre del clúster de la base de datos, que asignaste cuando lo creaste.
    • KEYTAB_SECRET_NAME: el nombre del archivo keytab que has creado.

    • PG_HBA_ENTRIES: pg_hba.conf entradas como una lista de cadenas. Estas entradas sobrescriben las entradas predeterminadas de pg_hba.conf. Si añades una configuración no válida, los usuarios no podrán iniciar sesión.

      En el ejemplo anterior, has añadido entradas para la autenticación basada en GSS seguida de la autenticación basada en contraseñas. Esto significa que el usuario ha iniciado sesión mediante la API GSS. Si este método de inicio de sesión falla, se usará la autenticación basada en contraseñas como alternativa.

      Para obtener más información, consulta el artículo El archivo pg_hba.conf.

    • PG_IDENT_ENTRIES: pg_ident.conf entradas 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

Crear roles de base de datos como usuario de Active Directory

  1. 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;

  2. Inicia sesión en la base de datos con el usuario de Active Directory. Debes tener kinit habilitado en el cliente al que te conectes. En este ejemplo, el pod postgres-client tiene instalados kinit y psql, y está configurado para conectarse al clúster de AlloyDB Omni mediante 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.

  3. Ejecutar consultas de SQL.

    username=# select * from TABLE_NAME;

Inhabilitar 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

Siguientes pasos