Integrar o suporte a usuários do Active Directory no Kubernetes

Selecione uma versão da documentação:

Neste documento, descrevemos como ativar a integração do Active Directory no cluster de banco de dados do AlloyDB Omni baseado no Kubernetes para permitir que os usuários atuais do Active Directory acessem o banco de dados do AlloyDB Omni. A integração do Active Directory oferece autorização usando GSSAPI para usuários autenticados com o mecanismo Kerberos para acessar o AlloyDB Omni.

Para mais informações, consulte Visão geral do Active Directory.

Este documento pressupõe que você já sabe como aplicar arquivos de manifesto do Kubernetes e usar a ferramenta de linha de comando kubectl. Para mais informações, consulte Ferramenta de linha de comando (kubectl).

Antes de começar

Para ativar a integração do Active Directory, você precisa ter o seguinte:

  • Um cluster do AlloyDB Omni implantado em um ambiente do Kubernetes
  • Um keytab do servidor do Active Directory

Migrar do operador AlloyDB Omni no Kubernetes 1.4.0 para 1.5.0

Se você estiver usando a integração do Active Directory na versão 1.4.0 ou anterior do operador do AlloyDB Omni, migre para a versão 1.5.0.

Para migrar para a versão 1.5.0 do operador do AlloyDB Omni, siga estas etapas:

  1. Faça upgrade do operador do AlloyDB Omni para a versão 1.5.0.
  2. Crie um recurso de autenticação definido pelo usuário.
    1. Crie um novo manifesto de recurso UserDefinedAuthentication.
    2. Preencha spec.dbclusterRef com o nome do DBCluster de destino.
    3. Preencha spec.keytabSecretRef com o nome do secret do keytab.
    4. Copie as regras pg_hba.conf relevantes para a autenticação do Active Directory e do Kerberos no campo spec.pgHbaEntries.
    5. Copie o pg_ident.conf rules atual (se houver) no campo spec.pgIdentEntries.
    6. Aplique esse novo manifesto, por exemplo, kubectl apply -f user-auth-crd.yaml.
  3. Remova a configuração de prévia e reimplante o cluster.
    1. Na definição do recurso DBCluster, remova todas as anotações que você usou anteriormente para configurar a integração do Active Directory, por exemplo, regras de autenticação baseada em host (HBA), regras de identificação e anotação de arquivo keytab.
    2. Exclua os ConfigMaps pg_hba e pg_ident que você criou.
    3. Reaplique o manifesto atualizado do DBCluster.

Configurar o suporte do Active Directory

  1. Crie e aplique um secret com a keytab:

    apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT

    Confira a seguir um exemplo de comando que gera um keytab no servidor do Active Directory:

    ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH

    ALLOYDB_HOST é o host que aponta para o DBCluster ou o endereço IP do DBCluster.

  2. Aplique o seguinte manifesto de recurso personalizado de autenticação definida pelo usuário:

    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

    Substitua:

    • USER_DEFINED_AUTHENTICATION_NAME: o nome do UserDefinedConfiguration. Por exemplo, DB_CLUSTER_NAME-ad-auth.
    • DB_CLUSTER_NAMESPACE: o namespace do Kubernetes para este plano de backup. O namespace precisa corresponder ao do cluster de banco de dados.
    • DB_CLUSTER_NAME: o nome do cluster de banco de dados, que você atribuiu ao criá-lo.
    • KEYTAB_SECRET_NAME: o nome do keytab que você criou.

    • PG_HBA_ENTRIES: entradas pg_hba.conf como uma lista de strings. Essas entradas substituem as entradas padrão em pg_hba.conf. Se você adicionar uma configuração inválida, os usuários não poderão fazer login.

      No exemplo anterior, você adicionou entradas para autenticação baseada em GSS seguida da autenticação baseada em senha. Isso significa que o usuário está conectado usando a API GSS. Se essa abordagem de login falhar, a autenticação com base em senha será usada como alternativa.

      Para mais informações, consulte o arquivo pg_hba.conf (em inglês).

    • PG_IDENT_ENTRIES: entradas pg_ident.conf como uma lista de strings. Para implementar o mapeamento de nomes de usuário, especifique map= no campo de opções do arquivo pg_hba.conf. Para mais informações, consulte Mapas de identificação.

      Veja o exemplo a seguir:

       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

Criar funções de banco de dados como um usuário do Active Directory

  1. Crie uma função no banco de dados que corresponda ao usuário do Active Directory. Para criar uma função para seu usuário do Active Directory, conecte-se ao cluster e execute os seguintes comandos:

    username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;

  2. Faça login no banco de dados usando o usuário do Active Directory. É necessário ativar o kinit no cliente em que você está se conectando. Neste exemplo, o pod postgres-client tem o kinit e o psql instalados e está configurado para se conectar ao cluster do AlloyDB Omni usando o 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. Executar consultas SQL.

    username=# select * from TABLE_NAME;

Desativar a autenticação do Active Directory

Para desativar a autenticação do Active Directory, execute o seguinte comando do Helm:

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

O comando retorna a seguinte saída:

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

A seguir