Documentação do Oracle Cloud Infrastructure

Usando LDAP para Autorização

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

Você pode usar o LDAP (Lightweight Directory Access Protocol) como um serviço de informações de rede para fornecer informações de autorização ao serviço File Storage. O uso do LDAP para fornecer informações de autorização fornece 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 ao usar Kerberos. O LDAP não é necessário em todos os cenários do Kerberos, como quando a exportação está expandindo tudo.

Pesquisa de Grupo Secundário

Os sistemas de arquivos do serviço File Storage autorizam o acesso usando o UID/GID da operação de 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 serviç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 a partir de um servidor LDAP permite que a solicitação de autorização use até 256 grupos.

Se a pesquisa de grupo secundário usando o mapeamento de ID estiver ativada, mas não estiver configurada, configurada incorretamente ou o serviço LDAP estiver indisponível, o serviç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 Ativado? Resposta LDAP Exportar Squash Ativado? Solicitação NFS
Qualquer um Qualquer um Sim (todos)

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

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

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

Não há lista de grupos secundários.
Número Não se aplica Número Prossegue com UID/GIDs do cabeçalho RPC.
Sim Correspondência de UID Número Usa a lista de grupos secundários recuperada do servidor LDAP.
Sim Não há correspondência de UID nem erro LDAP Número Prossegue com UID/GIDs do cabeçalho RPC. Não há lista de grupos secundários.
Importante

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

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

Cache

O serviço File Storage usa somente um modelo de cache sob demanda na memória 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 serviço File Storage contata seu servidor LDAP para obter informações de autorização. O serviço File Storage armazena no cache as informações de autorização, positivas ou negativas, para uso em operações NFS subsequentes.

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

  • Intervalo de Atualização do Cache em Segundos: O tempo que o ponto de acesso NFS deve permitir que uma entrada persista no cache antes de tentar atualizar a entrada. Escolha um valor que equilibre as implicações de segurança e um carregamento 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 se basear em OpenLDAP ou Microsoft Active Directory. A configuração personalizada pode ser necessária para o suporte ao serviço File Storage 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 pesquisar informações de usuário e grupo RFC2307-compliant.

    • 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 procure 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 de DNS na porta TCP/UDP 53.
  2. Comunicação com o serviço LDAP gerenciado pelo cliente na porta TCP configurada no conector de saída. O valor padrão é a porta TCP 636.
  3. Dados criptografados em armazenamento no serviço File Storage.

Infraestrutura LDAP

O serviço File Storage 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 conexão para o servidor LDAP e a base de pesquisa para usuários e grupos.

Para permitir que o serviço File Storage atinja o servidor LDAP, certifique-se do seguinte:

  • O firewall do servidor LDAP deve permitir tráfego de entrada do ponto de acesso NFS do serviço File Storage usando TCP 636 (padrão).
  • Qualquer lista de segurança e NSGs em uso deve permitir o tráfego do servidor LDAP e do ponto de acesso NFS.
  • 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 OCI DNS 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 OCI DNS Privado com zonas privadas - As zonas de DNS para um domínio personalizado são hospedadas no OCI DNS. Com essa opção, não há necessidade de gerenciar seu próprio servidor DNS, porque o 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 - Quando você cria 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 serviço File Storage não suporta SSLv2, SSLv3, TLSv1 ou TLSv1.1 para autorização LDAPS. O serviço File Storage 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 serviço File Storage possa procurar informações de usuário e grupo RFC2307-compliant 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 baseados nas Métricas do Sistema de Arquivos que ajudam a descobrir e diagnosticar rapidamente problemas de conectividade LDAP.

Monitoramento e Alarmes

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

Os alarmes construídos com base nos erros de conexão LDAP e nos 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 serviço File Storage precisa acessar segredos do serviço Vault de senha do servidor LDAP. O usuário que está configurando 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 ao grupo que está criando as permissões de segredo do serviço Vault. Para obter mais informações, consulte Gerenciando Segredos do Serviço Vault.

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

Conceda ao usuário ou ao grupo configurar o LDAP em uma permissão 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 serviço File Storage que leem os segredos do serviço 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 serviço File Storage usa recursos principais para conceder a um conjunto específico de pontos de acesso NFS ao segredo do serviço 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 destinos de montagem acesso de leitura aos segredos do serviço Vault:

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