Esta página documenta a versão 16.8.0 do AlloyDB Omni através da opção de implementação do Kubernetes. Escolha uma opção de implementação diferente.

Esta página foi traduzida pela API Cloud Translation.

Integre o suporte de grupos do Active Directory no Kubernetes

Selecione uma versão da documentação:

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.

Esta página descreve como configurar e gerir a autenticação e a autorização baseadas em grupos do Active Directory no AlloyDB Omni implementado no Kubernetes. O suporte baseado em grupos do Active Directory automatiza a gestão das associações de funções do PostgreSQL com base nas associações de grupos de um utilizador no seu Active Directory, o que simplifica a gestão de utilizadores e garante que as autorizações estão sincronizadas. 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).

Fluxo de trabalho de integração do Active Directory

A integração do Active Directory é implementada através de uma extensão do PostgreSQL (google_pg_auth) no seguinte fluxo de trabalho:

Início de sessão do utilizador: um utilizador autentica-se no AlloyDB Omni através das respetivas credenciais padrão do Active Directory com a interface de programação de aplicações (API) de serviços de segurança genéricos (GSSAPI).
Criação automática de funções: se não existir uma função PostgreSQL correspondente para o utilizador, o sistema cria automaticamente uma, por exemplo, CREATE ROLE "user@REALM" WITH LOGIN;.
Verificação de grupos LDAP: o sistema liga-se de forma segura ao seu Active Directory através do LDAP para obter as inscrições em grupos atuais do utilizador.
Sincronização de membros: o sistema compara os grupos do Active Directory do utilizador com os mapeamentos que configurou.
- Se o utilizador estiver num grupo do Active Directory mapeado, mas não estiver no grupo do PostgreSQL correspondente, é-lhe concedida a associação.
- Se o utilizador não estiver num grupo do Active Directory mapeado, mas estiver no grupo do PostgreSQL correspondente, a associação do utilizador é revogada.
Início de sessão concluído: a ligação do utilizador é finalizada e o utilizador tem sessão iniciada na base de dados. As autorizações do utilizador são determinadas pelas funções do PostgreSQL às quais pertence, que estão sincronizadas com o respetivo estado do grupo do Active Directory.

Esta sincronização ocorre automaticamente em cada início de sessão do utilizador, o que garante que os direitos de acesso do PostgreSQL refletem o estado atual do seu Active Directory.

Antes de começar

Antes de integrar o suporte de grupos do Active Directory com o AlloyDB Omni, certifique-se de que cumpre os seguintes requisitos.

Autenticação GSSAPI: tem de ter a autenticação baseada em GSSAPI configurada e operacional para a sua instância do AlloyDB Omni. Para mais informações, consulte o artigo Integre o Active Directory com o AlloyDB Omni.
Funções de grupo do PostgreSQL: tem de criar manualmente as funções de grupo do PostgreSQL que quer mapear para grupos do Active Directory, como mostrado no seguinte exemplo:
```
CREATE ROLE "postgres_developers";
CREATE ROLE "postgres_read_only";
```
Autorizações: tem de atribuir manualmente as autorizações da base de dados, por exemplo, SELECT e INSERT, a estas funções de grupo do PostgreSQL. A integração apenas gere a subscrição, mas não gere os privilégios dos próprios grupos, como mostrado no exemplo seguinte:
```
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;
```

Configure o suporte de grupos do Active Directory

Para configurar o suporte de grupos do Active Directory, tem de aplicar um UserDefinedAuthentication recurso personalizado no cluster de base de dados existente.

Configure o AlloyDB Omni com as credenciais do servidor LDAP. Aplique o manifesto de recurso personalizado de autenticação definido pelo utilizador seguinte:

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

Faça as seguintes substituições:

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.
LDAP_URI: URI do servidor LDAP, por exemplo, ldaps://ad.example.com:636.
LDAP_BASE_DN: DN de base para pesquisas LDAP. (por exemplo, DC=ad,DC=alloydb,DC=COM)
LDAP_BIND_DN: nome distinto (DN) do utilizador de associação LDAP.
LDAP_PASSWORD_SECRET_REF: referência ao segredo do Kubernetes com a palavra-passe do LDAP. A chave deste segredo tem de ser password.
LDAPS_CERT_SECRET_REF: (Opcional) Referência ao segredo do Kubernetes com o certificado LDAPS. A chave deste segredo tem de ser ldap.crt.
CACHE_TTL_SECONDS: (Opcional) Tempo máximo de espera antes de acionar uma sincronização de associação a grupos LDAP em segundos. A predefinição são 3600 segundos.
LDAP_CONNECTION_TIMEOUT: (Opcional) Tempo limite da ligação LDAP em milissegundos. A predefinição é 5000 ms.

Veja o exemplo seguinte:

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

Faça a gestão dos mapeamentos de grupos

Pode criar e gerir mapeamentos entre grupos do Active Directory e funções do PostgreSQL através de funções SQL.

Inicie sessão no cluster e carregue a extensão

Ligue-se ao AlloyDB Omni em execução no 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

Crie um mapeamento de grupos

Para mapear um grupo do Active Directory para uma função de grupo do PostgreSQL que já criou, use a função map_ad_group().

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

No exemplo seguinte, o grupo do ad-developers Active Directory está mapeado para a função do pg-developers PostgreSQL:

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

Para obter o SID de um grupo específico no Active Directory, use o seguinte comando no servidor do Active Directory:

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

Remova um mapeamento de grupos

Para remover um mapeamento existente, use a função unmap_ad_group(), que interrompe a sincronização para esse grupo. A função unmap_ad_group() não remove utilizadores do grupo PostgreSQL se já forem membros.

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

Veja o exemplo seguinte:

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

Crie um mapeamento de utilizadores

Para mapear um utilizador individual do Active Directory para uma função do PostgreSQL que já criou, use a função map_ad_user().

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

Por exemplo, para mapear o utilizador do quinn@google.com Active Directory para a função do pg-developers PostgreSQL, faça o seguinte:

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

Remova um mapeamento de utilizador

Para remover um mapeamento existente, use a função unmap_ad_user().

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

Por exemplo, para anular a associação do utilizador do quinn@google.com Active Directory à função do pg-developers PostgreSQL, faça o seguinte:

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

Associe à base de dados AlloyDB Omni

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

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

O seu acesso na base de dados do AlloyDB Omni é determinado automaticamente com base no seguinte:

A sua associação atual a grupos do Active Directory.
Os mapeamentos definidos pelo administrador entre esses grupos do Active Directory e as funções do PostgreSQL.
As autorizações concedidas pelo administrador a essas funções do PostgreSQL.

Se for a primeira vez que faz a associação, a função de utilizador do PostgreSQL (your_ad_user@YOURDOMAIN.COM) é criada automaticamente.

Sempre que inicia sessão, o sistema verifica as suas associações atuais ao grupo do Active Directory e atualiza as associações de funções correspondentes do PostgreSQL para corresponderem. Não tem de fazer nada de específico para que esta sincronização ocorra.

Exemplo de ligação à base de dados

No exemplo seguinte, o utilizador Quinn faz parte de um grupo do Active Directory denominado ad_developers. O administrador mapeou ad_developers para uma função do postgres com o nome postgres_read_only. Esta função tem acesso de leitura a uma tabela denominada sales. Quando o utilizador inicia sessão, pode aceder à tabela.

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

No exemplo seguinte, Quinn é removido do grupo ad_developers no 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

Limitações

Gestão manual de grupos e autorizações: esta funcionalidade apenas automatiza a associação de utilizadores a grupos PostgreSQL existentes. A criação desses grupos e a concessão das respetivas autorizações são tarefas administrativas manuais.
Latência de sincronização: a associação só é sincronizada quando um utilizador inicia sessão. As alterações feitas à associação de um utilizador a um grupo no Active Directory só se refletem no AlloyDB Omni na sessão de início de sessão seguinte do utilizador.
Desempenho: a pesquisa LDAP adiciona uma pequena quantidade de latência ao processo de início de sessão do utilizador inicial. O armazenamento em cache ajuda a mitigar esta latência para inícios de sessão subsequentes dentro do tempo de vida configurado (auth_cache_ttl_sec).
Processamento de erros: se o servidor LDAP estiver inacessível ou se ocorrerem outros erros durante o processo de sincronização, o AlloyDB Omni regista o erro. No entanto, o início de sessão do utilizador continua a ser bem-sucedido, uma vez que a autenticação GSSAPI foi bem-sucedida. Apenas a sincronização de membros do grupo para essa sessão falha.