Integrar o Active Directory ao AlloyDB Omni 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.

A configuração do Active Directory no AlloyDB Omni é opcional e fica desativada por padrão. Somente ambientes que usam o servidor do Active Directory para autenticação podem usar esse mecanismo de configuração.

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

Ativar a autenticação do Active Directory

Para ativar 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=true

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

Verificar o status da autenticação do Active Directory

Para determinar o status da autenticação do Active Directory, siga estas etapas:

  1. Para receber a implantação args atual do controlador de frota e garantir que enable-user-defined-authentication esteja definido como true, execute os seguintes comandos:

    kubectl get deployment -n alloydb-omni-system fleet-controller-manager -o json | jq '.spec.template.spec.containers[0].args'

[
  "--health-probe-bind-address=:8081",
  "--metrics-bind-address=127.0.0.1:8080",
  "--leader-elect",
  "--image-registry=gcr.io",
  ...
  "--enable-user-defined-authentication=true"
]

  2. Extraia os argumentos de implantação atuais do controlador local e verifique se enable-user-defined-authentication está definido como true executando os seguintes comandos:

    kubectl get deployment -n alloydb-omni-system local-controller-manager -o json | jq '.spec.template.spec.containers[0].args'

[
  "--health-probe-bind-address=:8081",
  "--metrics-bind-address=127.0.0.1:8080",
  "--leader-elect",
  "--deployment-platform=generic-k8s",
  "--enable-backup-from-standby=true",
  "--enable-user-defined-authentication=true"
]

Configurar o suporte do Active Directory

  1. Crie e aplique um ConfigMap usando entradas de arquivo pg_hba.conf:

    kubectl apply -f - 
apiVersion: v1
kind: ConfigMap
metadata:
  name: pg-hba-config
data:
  pg_hba_entries: |
    # Active Directory-based users
    hostgssenc all all 0.0.0.0/0    gss
    hostgssenc all all ::1/128      gss
    # Database-based users
    hostssl    all all 0.0.0.0/0  scram-sha-256
    hostssl    all all ::/0       scram-sha-256
EOF

    Modifique essas entradas com base nos seus requisitos. 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 pela autenticação baseada em senha. Isso significa que o usuário vai fazer login usando a API GSS. Se essa abordagem de login falhar, a autenticação baseada em senha será usada como alternativa.

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

  2. Crie e aplique um secret com a keytab:

     kubectl apply -f - 
 apiVersion: v1
 kind: Secret
 metadata:
   name: db-keytab-dbcluster-sample
 type: Opaque
 data:
   krb5.keytab: |
    BASE64_ENCODED_KEYTAB
 EOF

  3. Opcional: crie e aplique um ConfigMap usando entradas pg_ident.conf.

      kubectl apply -f - EOF
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: pg-ident-config
  data:
    pg_ident_entries: |
    
      MAP_NAME /^(.)@YOUR.REALM$/        \1
      MAP_NAME /^(.)@your.realm$/        \1
  EOF

    Para implementar o mapeamento de nomes de usuário, especifique map=MAP_NAME no campo de opções do arquivo pg_hba.conf.

    Para mais informações, consulte Mapas de identificação.

  4. Para ativar a integração do Active Directory, adicione anotações à especificação DBCluster.

    kubectl apply -f - DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  annotations:
    dbs.dbadmin.goog.com/pg-hba-config-map: pg-hba-config
    dbs.dbadmin.goog.com/pg-ident-config-map: pg-ident-config
    dbs.dbadmin.goog.com/keytab-ref: db-keytab-dbcluster-sample
spec:
  databaseVersion: "DB_VERSION"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      memory: MEMORY_SIZE
      cpu: CPU_COUNT
      disks:
      - name: DataDisk
        size: DISK_SIZE
EOF

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.

    kubectl exec -it postgres -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 ;

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

É possível verificar o status da autenticação do Active Directory.

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