Integre o apoio técnico de utilizadores do Active Directory no Kubernetes

Selecione uma versão da documentação:

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.

Para mais informações, consulte o artigo Vista geral do Active Directory.

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

Migre do operador do Kubernetes do AlloyDB Omni 1.4.0 para 1.5.0

Se estiver a usar a integração do Active Directory no operador do AlloyDB Omni versão 1.4.0 ou anterior, tem de migrar para o operador do AlloyDB Omni versão 1.5.0.

Para migrar para a versão 1.5.0 do operador do AlloyDB Omni, siga estes passos:

  1. Atualize o operador do AlloyDB Omni para a versão 1.5.0.
  2. Crie um recurso de autenticação definido pelo utilizador.
    1. Crie um novo manifesto de recursos UserDefinedAuthentication.
    2. Preencha spec.dbclusterRef com o nome do DBCluster de destino.
    3. Preencha spec.keytabSecretRef com o nome do segredo do keytab.
    4. Copie as regras pg_hba.conf existentes relevantes para o Active Directory e a autenticação Kerberos para o campo spec.pgHbaEntries.
    5. Copie o valor existente pg_ident.conf rules (se existir) para o campo spec.pgIdentEntries.
    6. Aplique este novo manifesto, por exemplo, kubectl apply -f user-auth-crd.yaml.
  3. Remova a configuração de pré-visualização e volte a implementar o cluster.
    1. Na definição do recurso DBCluster, remova todas as anotações que usou anteriormente para configurar a integração do Active Directory, por exemplo, regras de autenticação baseadas no anfitrião (HBA), regras ident e anotação de ficheiro keytab.
    2. Elimine os mapas de configuração pg_hba e pg_ident que criou.
    3. Volte a aplicar o manifesto DBCluster atualizado.

Configure o apoio técnico do Active Directory

  1. Crie e aplique um segredo com o keytab:

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

    Segue-se um exemplo de um 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 anfitrião que aponta para o DBCluster ou o endereço IP do DBCluster.

  2. Aplique o seguinte manifesto de recurso personalizado de autenticação definido pelo utilizador:

    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 o seguinte:

    • USER_DEFINED_AUTHENTICATION_NAME: o nome da UserDefinedConfiguration, por exemplo, DB_CLUSTER_NAME-ad-auth.
    • DB_CLUSTER_NAMESPACE: o namespace do Kubernetes para este plano de cópia de segurança. O espaço de nomes tem de corresponder ao espaço de nomes do cluster da base de dados.
    • DB_CLUSTER_NAME: o nome do cluster da base de dados que atribuiu quando o criou.
    • KEYTAB_SECRET_NAME: o nome do keytab que criou.
    • PG_HBA_ENTRIES: pg_hba.conf entradas como uma lista de strings. 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 em GSS, seguida da autenticação baseada em palavra-passe. Isto significa que o utilizador tem sessão iniciada através da API GSS. Se esta abordagem de início de sessão falhar, a autenticação baseada em palavra-passe é usada como alternativa.

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

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

      Veja o exemplo seguinte:

       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
      

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, ligue-se 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. Neste exemplo, o pod tem o kinit e o psql instalados e está configurado para se ligar ao cluster do AlloyDB Omni através do cliente psql.postgres-client

    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;
    

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

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

O que se segue?