Integre o Active Directory com o AlloyDB Omni no Kubernetes

Selecione uma versão da documentação: 16.3.0

• Atual (16.8.0)
• 16.8.0
• 16.3.0

Pré-visualização — AlloyDB Omni

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Pode tratar dados pessoais para esta funcionalidade conforme descrito na Alteração ao Tratamento de Dados do Cloud, sujeito às obrigações e restrições descritas no contrato ao abrigo do qual acede ao Google Cloud. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Este documento descreve como ativar a integração do Active Directory no cluster de base de dados AlloyDB Omni baseado em Kubernetes para que possa permitir que os utilizadores existentes baseados no Active Directory acedam à sua base de dados AlloyDB Omni. A integração do Active Directory fornece autorização através da GSSAPI para utilizadores autenticados através do mecanismo Kerberos para aceder ao AlloyDB Omni.

Nota: a integração do Active Directory só está disponível no AlloyDB Omni versão 16.3.0 e superior.

A configuração do Active Directory no AlloyDB Omni é opcional e está desativada por predefinição. Apenas os ambientes que usam o servidor do Active Directory para autenticação podem usar este mecanismo de configuração.

Este documento pressupõe que está familiarizado com a aplicação de ficheiros de manifesto do Kubernetes e com a utilização da ferramenta de linha de comandos kubectl. Para mais informações, consulte o artigo Ferramenta de linhas de comando (kubectl).

Antes de começar

Para ativar a integração do Active Directory, tem de ter o seguinte:

• Um cluster do AlloyDB Omni implementado num ambiente do Kubernetes
• Um keytab do servidor Active Directory

Ative a autenticação do Active Directory

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

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

O comando devolve o seguinte 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

Verifique o estado de autenticação do Active Directory

Para determinar o estado da autenticação do Active Directory, siga estes passos:

1. Obtenha a implementação atual args para o controlador da frota e certifique-se de que enable-user-defined-authentication está 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. Obtenha os argumentos de implementação atuais para o controlador local e certifique-se de que 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"
   ]
   

Configure o apoio técnico do Active Directory

1. Crie e aplique um mapa de configuração através de entradas de ficheiros 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 estas entradas com base nos seus requisitos. Estas entradas substituem as entradas predefinidas em pg_hba.conf. Se adicionar uma configuração inválida, os utilizadores não podem iniciar sessão.

   No exemplo anterior, adicionou entradas para a autenticação baseada no GSS, seguida da autenticação baseada em palavras-passe. Isto significa que o utilizador vai iniciar sessão através da API GSS. Se esta abordagem de início de sessão falhar, é usada a autenticação baseada em palavra-passe como alternativa.

   Para mais informações, consulte o artigo O ficheiro pg_hba.conf.

2. Crie e aplique um segredo com o keytab:

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

   Nota: para obter o keytab codificado em base64, use este comando de exemplo: cat postgres.keytab |base64.

3. Opcional: crie e aplique um mapa de configuração com 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 utilizador, especifique map=MAP_NAME no campo de opções no ficheiro pg_hba.conf.

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

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

   Nota: a integração do Active Directory só está disponível no AlloyDB Omni versão 16.3.0 e superior.

   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
   

Crie funções de base de dados como utilizador do Active Directory

1. Crie uma função na sua base de dados que corresponda ao utilizador do Active Directory. Para criar uma função para o utilizador do Active Directory, estabeleça ligação ao cluster e execute os seguintes comandos:

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

2. Inicie sessão na base de dados com o utilizador do Active Directory. Tem de ter a opção kinit ativada no cliente ao qual está a estabelecer ligação.

   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 ;
   

Desative a autenticação do Active Directory

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

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

Pode verificar o estado da autenticação do Active Directory.

O comando devolve o seguinte 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

Nota: quando ativa a autenticação do Active Directory através de anotações, a autenticação modifica o ficheiro pg_hba.conf, que permanece nesse estado modificado até ao reinício. Quando isto acontece, acione um reinício dos pods para repor pg_hba.conf. Tem de acionar um reinício porque, quando desativa a autenticação definida pelo utilizador, as entradas em pg_hba.conf não são repostas para as predefinições até o pod ser reiniciado.