Documentação do Oracle Cloud Infrastructure

Usando LDAP para Autorização

Saiba como usar o LDAP para autorização com o File Storage.

Você pode usar o LDAP (Lightweight Directory Access Protocol) como um serviço de informação de rede para fornecer informações de autorização ao File Storage Service. O uso do LDAP para fornecer informações de autorização oferece os seguintes benefícios:

  • Gerenciamento centralizado de usuários e grupos UNIX.
  • Suporte para até 256 grupos UNIX. Se você ativar o LDAP para grupos UNIX secundários em vez de usar a lista de grupos fornecida no cabeçalho RPC de uma solicitação NFS, você não estará sujeito à limitação AUTH_SYS de 16 grupos.
  • A infraestrutura LDAP é um requisito para autenticação por usuário durante o uso do Kerberos. O LDAP não é necessário para todos os cenários do Kerberos, como quando a exportação está esmagando tudo.

Pesquisa de Grupo Secundário

Os sistemas de arquivos do File Storage autorizam o acesso usando o UID/GID da operação NFS e a lista de grupos UNIX secundários. Por padrão, AUTH_SYS usa a lista de grupos fornecida no cabeçalho RPC da solicitação NFS.

Quando a autorização LDAP está ativada, o File Storage usa o UID UNIX do cabeçalho RPC da solicitação NFS para recuperar a lista de grupos UNIX secundários do servidor LDAP para acesso AUTH_SYS. O GIDLIST existente no cabeçalho RPC é substituído pelo GIDLIST do servidor LDAP. A recuperação de grupos UNIX secundários de um servidor LDAP permite que a solicitação de autorização use até 256 grupos.

Se a pesquisa de grupo secundário usando mapeamento de ID estiver ativada, mas não configurada, configurada incorretamente ou o serviço LDAP estiver indisponível, o File Storage não poderá atualizar a lista de grupos secundários usada na solicitação. Isso pode resultar em erros de permissões.

Cenários de Solicitação NFS para AUTH_SYS
LDAP para Lista de Grupos Ativada? Resposta LDAP Exportar Squash Ativado? Solicitação NFS
Qualquer um Qualquer um Sim (todos)

Se eliminar tudo, continuará com Squash UID e Squash GID definidos nas opções de exportação.

Não lista de grupos secundários.
Qualquer um Qualquer um Sim (raiz)

Se a raiz de squashing continuar com UID de Squash e GID de Squash definidos nas opções de exportação somente se o UID for 0.

Não lista de grupos secundários.
No Não aplicável No Continua com UID/GIDs do cabeçalho RPC.
Sim Correspondência de UID No Usa a lista de grupos secundários recuperada do servidor LDAP.
Sim Nenhuma correspondência de UID ou erro de LDAP No Continua com UID/GIDs do cabeçalho RPC. Não lista de grupos secundários.
Importante

Para usar LDAP para autorização, você deve Ativar LDAP para o ponto de acesso NFS e na exportação.

Se você estiver usando a autenticação do Kerberos junto com o LDAP, o comportamento será um pouco diferente. Para obter mais detalhes, consulte Pesquisas LDAP e Acesso Anônimo.

Cache

O File Storage usa um modelo de armazenamento em cache somente na memória sob demanda para armazenar informações de autorização para aumentar o desempenho e reduzir a carga no servidor LDAP.

Quando uma solicitação NFS é feita, o File Storage entra em contato com o servidor LDAP para obter informações de autorização. O Armazenamento de Arquivos armazena em cache as informações de autorização, positivas ou negativas, para uso em operações NFS subsequentes.

Você pode configurar por quanto tempo o File Storage armazena essas informações em cache ao configurar um ponto de acesso NFS para LDAP usando as seguintes opções:

  • Intervalo de Atualização em Cache em Segundos: O tempo que o ponto de acesso NFS deve permitir que uma entrada persista em seu cache antes de tentar atualizar a entrada. Escolha um valor que equilibre as implicações de segurança e uma carga aceitável no seu servidor LDAP.
  • Tempo de Vida em Cache em Segundos: A quantidade máxima de tempo que o ponto de acesso NFS pode usar uma entrada armazenada no cache. Se as entradas de cache não puderem ser atualizadas em tempo hábil por causa de carga ou falhas na infraestrutura do cliente, será útil usar entradas antigas até que a conectividade seja restaurada. Defina o valor para o período mais longo no qual você está disposto a ter uma entrada obsoleta no cache LDAP, incluindo casos de indisponibilidade do servidor LDAP por qualquer motivo.
  • Vida Útil do Cache Negativo em Segundos: O tempo que um ponto de acesso NFS mantém informações de que um usuário não é encontrado na configuração de mapeamento de ID. Se um usuário não for encontrado no banco de dados LDAP, o ponto de acesso NFS colocará uma entrada no cache observando que o usuário não existe. Escolha um valor que equilibre as implicações de segurança e uma carga aceitável no seu servidor LDAP.

Pré-requisitos

Requisitos:

  • Infraestrutura LDAP gerenciada pelo cliente, incluindo um servidor LDAP que suporta um esquema posix RFC2307. Os servidores LDAP podem ser baseados em OpenLDAP ou no Microsoft Active Directory. A configuração personalizada pode ser necessária para o suporte de Armazenamento de Arquivos do diretório LDAP.

  • Uma conta de log-in no servidor LDAP que um ponto de acesso NFS do serviço File Storage pode usar para procurar informações de usuário e grupo compatíveis com RFC2307.

    • O servidor LDAP deve ter os seguintes atributos de usuário:
      • ObjectClass: posixAccount - Esta classe de objeto fornece os seguintes atributos para o usuário.
      • uidNumber - ID do usuário UNIX.
      • gidNumber - ID do grupo UNIX do grupo principal do usuário.
      • uid - O nome de usuário do usuário
    • O servidor LDAP deve ter os seguintes atributos de grupo:
      • ObjectClass: posixGroup - Esta classe de objeto fornece os seguintes atributos para o grupo.
      • gidNumber - ID do grupo UNIX para o grupo
      • memberUid - O atributo uid dos usuários que são membros deste grupo. Este atributo pode ser adicionado várias vezes para ter vários usuários no grupo.
    Dica

    Você pode testar suporte ao esquema LDAP.
  • Um servidor DNS para permitir que o ponto de acesso NFS pesquise nomes de host, incluindo o servidor LDAP.
Esta imagem mostra a infraestrutura gerenciada pelo cliente e gerenciada pelo OCI necessária para autorização LDAP.
  1. Comunicação com o serviço DNS pela porta TCP/UDP 53.
  2. Comunicação com o serviço LDAP gerenciado pelo cliente por meio da porta TCP configurada no conector de saída. O valor default é a porta TCP 636.
  3. Dados criptografados em repouso no Armazenamento de Arquivos.

Infraestrutura LDAP

O Armazenamento de Arquivos requer um conector de saída para que os pontos de acesso NFS possam se comunicar com um servidor LDAP em sua porta LDAPS. O conector de saída requer que você forneça o nome de domínio totalmente qualificado (FQDN) do servidor LDAP, um nome de usuário e uma senha de bind para o servidor LDAP e a base de pesquisa para usuários e grupos.

Para permitir que o File Storage atinja o servidor LDAP, verifique o seguinte:

  • O firewall do servidor LDAP deve permitir o tráfego de entrada do ponto de acesso NFS do File Storage usando TCP 636 (padrão).
  • Qualquer lista de segurança e NSGs em uso deve permitir o tráfego do ponto de acesso NFS e do servidor LDAP.
  • O DNS está configurado para o ponto de acesso NFS e os clientes para resolver o nome do host. As opções de configuração de DNS incluem:
    • Usando o DNS do OCI com resolução padrão e nomes de host na sua VCN - Essa opção não oferece a flexibilidade de nomes de DNS personalizados. Os nomes de host terminam com oraclevcn.com com subdomínios para VCN e sub-rede. Consulte DNS na Sua Rede Virtual na Nuvem para obter mais informações.
    • Usando o DNS Privado do OCI com zonas privadas - As zonas de DNS de um domínio personalizado são hospedadas no DNS do OCI. Com essa opção, não há necessidade de gerenciar seu próprio servidor DNS, porque a OCI gerencia totalmente o DNS. Você deve gerenciar as zonas e os registros. Consulte DNS Privado para obter mais informações.
    • Usando um servidor DNS gerenciado pelo cliente - Ao criar uma VCN, não selecione Usar nomes de host DNS nesta VCN. Em vez disso, configure a VCN para usar seu próprio servidor DNS usando um dos seguintes métodos:
      1. Configure Opções de DHCP na sub-rede para usar um servidor DNS gerenciado pelo cliente.
      2. Use o resolvedor de VCN com um ponto final de encaminhamento e uma regra de encaminhamento para que as consultas de DNS na VCN sejam encaminhadas para um servidor DNS gerenciado pelo cliente.

O File Storage não suporta SSLv2, SSLv3, TLSv1 ou TLSv1.1 para autorização LDAPS. O Armazenamento de Arquivos suporta os seguintes conjuntos de cifras OpenSSL para autorização LDAPS:

  • DHE-DSS-AES128-GCM-SHA256
  • DHE-DSS-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384

Testando o Suporte a Esquema LDAP

Você pode usar as consultas de exemplo a seguir para garantir que o File Storage possa procurar informações de usuário e grupo compatíveis com RFC2307 de um servidor LDAP com uma configuração suportada.

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber
Exemplo de Saída da Consulta
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber
Exemplo de Saída da Consulta
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber
Exemplo de Saída da Consulta
$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Dica

Você pode criar alarmes com base em Métricas do Sistema de Arquivos que ajudam a descobrir e diagnosticar rapidamente problemas de conectividade LDAP.

Monitoramento e Alarmes

Tornar-se consciente de um problema rapidamente é importante ao usar o LDAP. Se a infraestrutura LDAP não estiver funcionando corretamente, os clientes NFS poderão perder o acesso aos sistemas de arquivos do File Storage disponibilizados por meio de suas exportações. Para descobrir esses problemas, recomendamos definir alarmes em métricas do ponto de acesso NFS. Os alarmes podem alertá-lo sobre problemas de infraestrutura em questão de minutos.

Os alarmes criados com base em erros de conexão LDAP e erros de solicitação LDAP detectam problemas de conectividade entre pontos de acesso NFS, conectores de saída e infraestrutura LDAP gerenciada pelo cliente.

A consulta de exemplo a seguir pode ser usada para criar um alarme para conectividade LDAP:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Para obter mais informações sobre o monitoramento de métricas e o uso de alarmes, consulte Visão Geral do Serviço Monitoring. Para obter informações sobre notificações de alarmes, consulte Visão Geral do Serviço Notifications.

Política Obrigatória do Serviço IAM

O Armazenamento de Arquivos precisa acessar segredos do Vault de senha do servidor LDAP. O usuário que configura o ponto de acesso NFS e o próprio ponto de acesso NFS precisam de acesso de leitura.

Importante

Essas políticas devem ser criadas para que você possa configurar pontos de acesso NFS para usar o LDAP para autorização.

Política para Gerenciar Segredos do Vault

Conceda ao usuário ou grupo que está criando as permissões de segredo do Vault. Para obter mais informações, consulte Gerenciando Segredos do Vault.

Política para Ativar a Configuração do Ponto de Acesso NFS

Conceda ao usuário ou grupo que configura o LDAP em permissões de ponto de acesso NFS usando uma política como a seguinte:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

Isso permite que o usuário emita comandos do File Storage que leem os segredos do Vault e exibam partes do segredo para validação durante a configuração.

Política para Permitir que um Ponto de Acesso NFS Recupere Segredos

O serviço File Storage requer a capacidade de ler os segredos. O File Storage usa controladores de recursos para conceder a um conjunto específico de pontos de acesso NFS acesso ao segredo do Vault. Este é um processo de duas etapas, primeiro os pontos de acesso NFS que precisam de acesso devem ser colocados em um grupo dinâmico e, em seguida, o grupo dinâmico recebe acesso para ler os segredos.

  1. Crie um grupo dinâmico para os pontos de acesso NFS com uma política como a seguinte:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Observação

    Se você tiver mais de uma regra no grupo dinâmico, certifique-se de usar a opção Match any rules defined below.

  2. Crie uma política do serviço IAM que dê ao grupo dinâmico de pontos de acesso NFS acesso de leitura aos segredos do Vault:

     allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>