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

Integra la compatibilidad con grupos de Active Directory en Kubernetes

Selecciona una versión de la documentación:

Vista previa — AlloyDB Omni

Esta función está sujeta a las "Condiciones de la oferta de la fase previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Puedes procesar datos personales para esta función, como se describe en el Anexo de Tratamiento de Datos de Cloud, sujeto a las obligaciones y restricciones que se describen en el acuerdo en virtud del cual accedes a Google Cloud. Las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se describe cómo configurar y administrar la autenticación y autorización basadas en grupos de Active Directory en AlloyDB Omni implementado en Kubernetes. La compatibilidad basada en grupos de Active Directory automatiza la administración de las membresías de roles de PostgreSQL según las membresías de grupos de un usuario en tu Active Directory, lo que optimiza la administración de usuarios y garantiza que los permisos estén sincronizados. 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).

Flujo de trabajo de integración de Active Directory

La integración de Active Directory se implementa con una extensión de PostgreSQL (google_pg_auth) en el siguiente flujo de trabajo:

Acceso del usuario: Un usuario se autentica en AlloyDB Omni con sus credenciales estándar de Active Directory a través de la interfaz de programación de aplicaciones de servicios de seguridad genéricos (GSSAPI).
Creación automática de roles: Si no existe un rol de PostgreSQL correspondiente para el usuario, el sistema crea uno automáticamente, por ejemplo, CREATE ROLE "user@REALM" WITH LOGIN;.
Verificación de grupos de LDAP: El sistema se conecta de forma segura a tu Active Directory a través de LDAP para recuperar las membresías de grupo actuales del usuario.
Sincronización de membresías: El sistema compara los grupos de Active Directory del usuario con las asignaciones que configuraste.
- Si el usuario pertenece a un grupo de Active Directory asignado, pero no al grupo de PostgreSQL correspondiente, se le otorga la membresía.
- Si el usuario no pertenece a un grupo de Active Directory asignado, pero sí al grupo de PostgreSQL correspondiente, se revoca su membresía.
Acceso completado: Se finaliza la conexión del usuario y se accede a la base de datos. Los permisos del usuario se determinan según los roles de PostgreSQL a los que pertenece, que están sincronizados con el estado de su grupo de Active Directory.

Esta sincronización se realiza automáticamente cada vez que un usuario accede, lo que garantiza que los derechos de acceso de PostgreSQL reflejen el estado actual de tu Active Directory.

Antes de comenzar

Antes de integrar la compatibilidad con grupos de Active Directory en AlloyDB Omni, asegúrate de cumplir con los siguientes requisitos.

Autenticación de GSSAPI: Debes tener configurada y operativa la autenticación basada en GSSAPI para tu instancia de AlloyDB Omni. Para obtener más información, consulta Integra Active Directory en AlloyDB Omni.
Roles de grupo de PostgreSQL: Debes crear manualmente los roles de grupo de PostgreSQL que deseas asignar a los grupos de Active Directory, como se muestra en el siguiente ejemplo:
```
CREATE ROLE "postgres_developers";
CREATE ROLE "postgres_read_only";
```
Permisos: Debes asignar manualmente los permisos de la base de datos (por ejemplo, SELECT y INSERT) a estos roles de grupo de PostgreSQL. La integración solo administra la membresía, pero no los privilegios de los grupos en sí, como se muestra en el siguiente ejemplo:
```
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO postgres_read_only;
GRANT USAGE ON SCHEMA finance TO postgres_developers;
GRANT USAGE ON SCHEMA sales TO postgres_read_only;
GRANT SELECT, INSERT ON finance.transactions TO postgres_developers;
```

Configura la compatibilidad con grupos de Active Directory

Para configurar la compatibilidad con grupos de Active Directory, debes aplicar un recurso personalizado UserDefinedAuthentication en tu clúster de base de datos existente.

Configura AlloyDB Omni con las credenciales del servidor LDAP. 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
ldapConfiguration:
   enableGroupMapping: true
   ldapURI: LDAP_URI
   ldapBaseDN: LDAP_BASE_DN
   ldapBindDN: LDAP_BIND_DN
   cacheTTLSeconds: CACHE_TTL_SECONDS
   ldap_connection_timeout_ms: LDAP_CONNECTION_TIMEOUT
   ldapBindPasswordSecretRef:
     name: LDAP_PASSWORD_SECRET_REF
   ldapsCertificateSecretRef:
     name: LDAPS_CERT_SECRET_REF

Realiza los siguientes reemplazos:

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.
LDAP_URI: URI del servidor LDAP, por ejemplo, ldaps://ad.example.com:636.
LDAP_BASE_DN: DN base para las búsquedas de LDAP. (p.ej., DC=ad,DC=alloydb,DC=COM)
LDAP_BIND_DN: Nombre distinguido (DN) para el usuario de vinculación de LDAP.
LDAP_PASSWORD_SECRET_REF: Es una referencia al secreto de Kubernetes con la contraseña de LDAP. La clave de este secreto debe ser password.
LDAPS_CERT_SECRET_REF: (Opcional) Es una referencia al Secret de Kubernetes con el certificado LDAPS. La clave de este secreto debe ser ldap.crt.
CACHE_TTL_SECONDS: (Opcional) Es el tiempo máximo de espera antes de activar una sincronización de membresía de grupo de LDAP en segundos. El valor predeterminado es 3,600 segundos.
LDAP_CONNECTION_TIMEOUT: (Opcional) Tiempo de espera de conexión LDAP en milisegundos. El valor predeterminado es 5,000 ms.

Consulta el siguiente ejemplo:

apiVersion: v1
kind: Secret
metadata:
  name: ldaps-secret
type: Opaque
data:
  ldap.crt: LDAPS_CERTIFICATE_CONTENT_BASE64_ENCODED
---
apiVersion: v1
kind: Secret
metadata:
  name: ldap-password-dbcluster-sample
type: Opaque
data:
  password: LDAPS_PASSWORD_CONTENT_BASE64_ENCODED
---
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-dbcluster-sample
type: Opaque
data:
  dbcluster-sample: POSTGRES_PASSWORD
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 16.8.0
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-dbcluster-sample
    resources:
      memory: 5Gi
      cpu: 1
      disks:
      - name: DataDisk
        size: 10Gi
---
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
  ldapConfiguration:
    enableGroupMapping: true
    ldapURI: ldaps://ad.alloydb.com:636
    ldapBaseDN: DC=ad,DC=alloydb,DC=COM
    ldapBindDN: read-only-admin@ad.alloydb.com
    cacheTTLSeconds: 60
    ldapBindPasswordSecretRef:
      name: ldap-password-dbcluster-sample
    ldapsCertificateSecretRef:
      name: ldaps-secret

Administra las asignaciones de grupos

Puedes crear y administrar asignaciones entre grupos de Active Directory y roles de PostgreSQL con funciones de SQL.

Accede al clúster y carga la extensión

Conéctate a AlloyDB Omni que se ejecuta en Kubernetes.

export DBPOD=`kubectl get pod --selector=alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}'`

kubectl exec -ti $DBPOD -n DB_CLUSTER_NAMESPACE -c database -- psql -h localhost -U postgres
postgres=# CREATE EXTENSION google_pg_auth;
CREATE EXTENSION

Crea una asignación de grupo

Para asignar un grupo de Active Directory a un rol de grupo de PostgreSQL que ya creaste, usa la función map_ad_group().

SELECT google_pg_auth.map_ad_group(ad_group_name TEXT, ad_group_sid TEXT, pg_role_name TEXT);

En el siguiente ejemplo, el grupo de Active Directory ad-developers se asigna al rol de PostgreSQL pg-developers:

SELECT google_pg_auth.map_ad_group('ad-developers', 'S-1-5-21-.....', 'postgres_read_only');

Para recuperar el SID de un grupo en particular en Active Directory, usa el siguiente comando en tu servidor de Active Directory:

C:\Users\Admin> Get-ADGroup -Identity ad-developers | select SID
            
             SID
-----------------------------------------------
S-1-5-21-3168537779-1985441202-1799118680-1612

Cómo quitar una asignación de grupo

Para quitar una asignación existente, usa la función unmap_ad_group(), que detiene la sincronización para ese grupo. La función unmap_ad_group() no quita a los usuarios del grupo de PostgreSQL si ya son miembros.

SELECT google_pg_auth.unmap_ad_group(ad_group_sid TEXT, pg_role_name TEXT);

Consulta el siguiente ejemplo:

SELECT google_pg_auth.unmap_ad_group('S-1-5-21-.....', ''postgres_read_only'');

Crea una asignación de usuario

Para asignar un usuario individual de Active Directory a un rol de PostgreSQL que ya creaste, usa la función map_ad_user().

SELECT google_pg_auth.map_ad_user(ad_username TEXT, pg_role_name TEXT);

Por ejemplo, para asignar el usuario de Active Directory quinn@google.com al rol de PostgreSQL pg-developers, haz lo siguiente:

SELECT google_pg_auth.map_ad_user('quinn@google.com', ''postgres_read_only'');

Cómo quitar una asignación de usuario

Para quitar una asignación existente, usa la función unmap_ad_user().

SELECT google_pg_auth.unmap_ad_user(ad_username TEXT, pg_role_name TEXT);

Por ejemplo, para anular la asignación del usuario de Active Directory quinn@google.com al rol de PostgreSQL pg-developers, haz lo siguiente:

SELECT google_pg_auth.unmap_ad_user('quinn@google.com', ''postgres_read_only'');

Conéctate a la base de datos de AlloyDB Omni

Accede a la base de datos de AlloyDB Omni con el usuario de Active Directory. Debes tener habilitado kinit en el cliente al que te conectas.

En el siguiente 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.

root@postgres-client:/# kinit AD_USER_NAME
Password for user1REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U AD_USER_NAME -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

user1=#

Tu acceso a la base de datos de AlloyDB Omni se determina automáticamente según lo siguiente:

Tu membresía actual en grupos de Active Directory
Las asignaciones que define el administrador entre esos grupos de Active Directory y los roles de PostgreSQL
Son los permisos que el administrador otorga a esos roles de PostgreSQL.

Si es la primera vez que te conectas, tu rol de usuario de PostgreSQL (your_ad_user@YOURDOMAIN.COM) se crea automáticamente.

Cada vez que accedes, el sistema verifica tus membresías actuales en grupos de Active Directory y actualiza tus membresías correspondientes en roles de PostgreSQL para que coincidan. No es necesario que realices ninguna acción específica para que se produzca esta sincronización.

Ejemplo de conexión a la base de datos

En el siguiente ejemplo, un usuario llamado Quinn forma parte de un grupo de Active Directory llamado ad_developers. El administrador asignó ad_developers a un rol de Postgres llamado postgres_read_only. Este rol tiene acceso de lectura a una tabla llamada sales. Cuando el usuario accede, puede acceder a la tabla.

root@postgres-client:/# kinit quinnREALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinnREALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will be run successfully

En el siguiente ejemplo, se quita a Quinn del grupo ad_developers en Active Directory.

root@postgres-client:/# kinit quinnREALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinnREALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will fail

Limitaciones

Administración manual de grupos y permisos: Esta función solo automatiza la membresía de los usuarios en los grupos de PostgreSQL existentes. La creación de esos grupos y el otorgamiento de sus permisos son tareas administrativas manuales.
Latencia de sincronización: La membresía solo se sincroniza cuando un usuario accede a su cuenta. Los cambios que se realicen en la membresía de un usuario en un grupo de Active Directory solo se reflejarán en AlloyDB Omni en la próxima sesión de acceso del usuario.
Rendimiento: La búsqueda de LDAP agrega una pequeña cantidad de latencia al proceso inicial de acceso del usuario. El almacenamiento en caché ayuda a mitigar esta latencia para los accesos posteriores dentro del tiempo de actividad configurado (auth_cache_ttl_sec).
Control de errores: Si no se puede acceder al servidor LDAP o si se producen otros errores durante el proceso de sincronización, AlloyDB Omni registra el error. Sin embargo, el acceso del usuario seguirá siendo exitoso, ya que la autenticación de GSSAPI se realizó correctamente. Solo fallará la sincronización de la membresía del grupo para esa sesión.