Documentação do Oracle Cloud Infrastructure

Usando a Autenticação do Kerberos

O serviço File Storage oferece autenticação Kerberos para fornecer uma opção de autenticação forte.

A segurança do NFS v.3 Unix, que confia no cliente NFS para que ele seja fiel à identidade de um usuário, oferece apenas segurança básica. A identidade do usuário em cada chamada NFS é definida pelo chamador e a identidade não é verificada por um terceiro confiável.

O Kerberos para NFSv3 oferece autenticação forte para hosts e usuários. Ele também pode oferecer prova da integridade dos dados, garantindo que os dados não sejam adulterados e protegendo a privacidade dos dados. A integridade e a privacidade dos dados não são possíveis com a segurança do NFS v.3 UNIX sem instalar software cliente especializado ou abrir mais portas TCP.

  • Os usuários e serviços em uma rede ativada para Kerberos são chamados de Principais. Um principal do Kerberos tem o formato primary/instance@realm. Consulte a documentação principal do MIT Kerberos para obter mais informações.
  • O Centro de Distribuição de Chaves (KDC) autentica principais e emite tickets. O KDC mantém uma lista de principais e suas senhas.
  • Um Realm consiste em todos os principais suportados por um KDC.

O serviço File Storage suporta a autenticação Kerberos por meio de RPCSEC_GSS (RFC2203) com as seguintes opções de segurança:

  • Modo de uso KRB5 para autenticação sobre NFS
  • Modo de uso KRB5I para autenticação sobre NFS e integridade de dados (modificação não autorizada de dados em trânsito)
  • Use o modo KRB5P para autenticação em NFS, integridade de dados e privacidade de dados (criptografia em trânsito)

Recursos

O suporte ao serviço File Storage do Kerberos inclui os recursos a seguir.

criptografia em trânsito

Você pode usar o modo Kerberos KRB5P, que oferece privacidade de dados, como uma alternativa ao uso da criptografia TLS v.1.2 (Transport Layer Security). A criptografia TLS v.1.2 requer a instalação de um pacote chamado oci-fss-utils ou o uso de stunnel, dependendo do seu sistema operacional. O número de conexões NFS/TLS criptografadas para um ponto de acesso NFS é limitado, mas o uso do Kerberos com a opção KRB5P permite usar criptografia em trânsito em uma escala que não é possível com NFS em TLS.

Kerberos e segurança por IP

A segurança por IP, definida usando opções de exportação NFS, será razoavelmente segura se os endereços IP estiverem no OCI e os hosts forem confiáveis. O Kerberos para NFSv3 pode fornecer um nível mais alto de segurança para ambientes mistos ou ambientes com hosts não confiáveis.

Você pode configurar um bloco CIDR para exigir o Kerberos e outro para autenticação NFS AUTH_SYS na mesma exportação. Qualquer cliente montado a partir da rede confiável não precisaria montado com o Kerberos, mas os clientes montados a partir da rede não confiável precisariam usar o Kerberos.

Pesquisas LDAP e Acesso Anônimo

Quando os usuários tiverem uma identidade no KDC, mas nenhuma informação adicional no servidor LDAP ou o LDAP não estiver ativado, a operação NFS poderá falhar ou continuar. O comportamento nesses casos depende de você ativar ou não o LDAP para o ponto de acesso NFS e o acesso anônimo para a exportação.

O acesso anônimo está desativado por padrão. Falha em qualquer solicitação NFS associada a um usuário não encontrado.

Se o acesso anônimo estiver ativado, as solicitações associadas a um usuário que não for encontrado no servidor LDAP continuarão com o UID de Tamanho e o GID de Tamanho definidos nas opções de exportação. Talvez você queira permitir o acesso anônimo se o processo de montagem usar um principal do Kerberos do sistema que não existe em seu servidor LDAP e os direitos squashed permitem que as poucas operações somente leitura usadas pelo cliente NFS montem o sistema de arquivos.

Cenários de Solicitação NFS para Exportações Ativadas para Kerberos
LDAP Ativado no Ponto de Acesso NFS? Resposta LDAP Acesso Anônimo Ativado? Exportar Squash Ativado? Solicitação NFS
Qualquer um Qualquer um Qualquer um Sim (todos)

Continua com Squash UID e Squash GID definidos nas opções de exportação. Não lista de grupos secundários.
Qualquer um Qualquer um Qualquer um Sim (raiz)

Continua com Squash UID e Squash GID definidos nas opções de exportação somente após uma resposta LDAP bem-sucedida em que o nome de usuário é mapeado para o UID 0. Não lista de grupos secundários.

Se a resposta LDAP retornar um UID que não seja 0, continuará com o UID, o GID e a lista de grupos retornados.
Sim Correspondência USERNAME Qualquer um Número Usa UID, GID e lista de grupos secundários recuperados do servidor LDAP.
Sim Nenhuma correspondência de USERNAME Sim Número Continua com Squash UID e Squash GID definidos nas opções de exportação. Não lista de grupos secundários.
Sim Nenhuma correspondência de USERNAME Número Número Falha com erro de permissões.
Sim Erro de LDAP diferente de nenhum usuário correspondente Qualquer um N.o Falha com erro de permissões.
N.o Não aplicável Sim N.o

Continua com Squash UID e Squash GID definidos nas opções de exportação.
N.o Não aplicável N.o N.o Falha com erro de permissões.
Observação

As exportações ativadas para Kerberos sempre usam Usar LDAP para Lista de Grupos quando a opção Ativar LDAP está ativada no ponto de acesso NFS.

Para obter mais informações, consulte Opções de Exportação NFS.

Pré-requisitos

O serviço File Storage requer vários pré-requisitos para usar o Kerberos para autenticação.

Os requisitos para usar a autenticação do Kerberos por usuário incluem:

  • Infraestrutura LDAP gerenciada pelo cliente para mapear principais do Kerberos para identidades UNIX. Para obter mais informações, consulte Pré-requisitos do LDAP para Autorização.
  • Infraestrutura Kerberos gerenciada pelo cliente, com um KDC, como MIT ou Microsoft Active Directory.
  • Um servidor DNS que pode resolver o nome e o endereço IP do ponto de acesso NFS. Os recursos de consulta direta e reversa são obrigatórios.
Esta imagem mostra a infraestrutura gerenciada pelo cliente e gerenciada pelo OCI necessária para autenticação do Kerberos.
  1. Comunicação com um servidor KDC gerenciado pelo cliente pela porta TCP/UDP 88.
  2. Comunicação segura com um ponto de acesso NFS ativado para Kerberos na porta NFS 2048/2049/2050 (opcionalmente criptografado).
  3. Comunicação com o serviço DNS pela porta TCP/UDP 53.
  4. 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.
  5. Dados criptografados em repouso no serviço File Storage.

Infraestrutura LDAP

O serviço File Storage usa UIDs e GIDs para autorizar o acesso a arquivos. O serviço File Storage usa LDAP para mapear principais do Kerberos para UIDs e GIDS. Para obter requisitos detalhados de infraestrutura LDAP, consulte Pré-requisitos para usar o LDAP para autorização.

Se o serviço File Storage não puder procurar informações de autorização do LDAP, os acessos NFS para o principal do Kerberos provavelmente falharão. A autenticação do Kerberos pode ser usada sem LDAP, mas todos os principais do Kerberos autenticados seriam tratados como anônimos. Para obter mais informações, consulte Pesquisas LDAP e Acesso Anônimo.

Keytab do Kerberos

A keytab Kerberos armazenada no serviço OCI Vault deve ser um array de string codificado em Base64 da seguinte estrutura: 

<principal, key version number, cipher type, symmetric key>

Cada entrada no keytab pode ter apenas um principal e esse principal deve incluir o nome de domínio totalmente qualificado (FQDN) do ponto de acesso NFS como sua instância. Um principal pode ter várias entradas com diferentes tipos de criptografia ou cifras.

Por exemplo, se nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM for o principal na keytab, FSS_EXAMPLE.COM será o realm, fss_test.com será a instância e nfs será o principal. O FQDN do ponto de acesso NFS neste exemplo deve ser krb_mt1.fss_test.com. Se estiver usando um servidor DNS gerenciado pelo cliente, você usaria esse FQDN em comandos de montagem.

Observação

Ao usar o Resolvedor padrão de Internet e VCN, o serviço File Storage constrói um FQDN combinando o nome de host do ponto de acesso NFS com o FQDN da sub-rede na qual o ponto de acesso NFS está localizado. Após a criação, o nome do host pode ser alterado na página de detalhes do ponto de acesso NFS. Consulte Gerenciando Pontos de Acesso NFS para obter mais informações.

O serviço File Storage suporta o seguinte conjunto de cifras:

  • aes128-cts-hmac-sha256-128
  • aes256-cts-hmac-sha384-192
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
Observação

O serviço OCI File Storage suporta um tamanho máximo de keytab Kerberos de 1024 bytes.
Importante

Valide o keytab do Kerberos antes de ativar o Kerberos para evitar uma interrupção de disponibilidade causada por um keytab inválido. É possível validar a keytab ao configurar ou revisar a configuração do Kerberos de um ponto de acesso NFS.

Quando você valida a keytab Kerberos por meio da Console, da CLI ou da API, o serviço File Storage verifica o seguinte:

  • Se o tamanho do keytab for maior que 1024 bytes
  • Que o número da versão do keytab não é 1281 ou 1282
  • Se o keytab contiver entradas nulas
  • Se o keytab tiver entradas com nomes principais diferentes
  • Se o keytab tiver mais de 12 entradas, que é o máximo
  • Se o tipo de codificação keytab não for um dos seguintes:
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Observação

Um keytab extraído do KDC em formato binário deve ser convertido em Base64 e usado para criar um segredo no serviço OCI Vault. Certifique-se de selecionar Base64 como o formato do segredo ao colar no keytab convertido.

O serviço File Storage suporta a rotação de keytab usando um keytab de backup. Consulte Chaves Rotativas para obter mais informações.

Considerações e limitações

Ao usar o Kerberos para autenticação do serviço File Storage, considere as informações e os limites a seguir.

  • Para autenticação Kerberos por usuário, o serviço File Storage requer uma infraestrutura LDAP (Lightweight Directory Access Protocol) gerenciada pelo cliente, incluindo um servidor LDAP que suporte um esquema POSIX RFC2307.
  • O serviço File Storage suporta um tamanho máximo de keytab Kerberos de 1024 bytes.

  • O serviço File Storage suporta o seguinte conjunto de cifras:

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • A montagem de sistemas de arquivos com as opções rsize ou wsize não é recomendada. Se você fornecer valores para essas opções, elas poderão ser reduzidas para 256 KB pelo serviço File Storage ao usar KRB5I ou KRB5P.
  • O desempenho do serviço File Storage ao usar o modo de autenticação Kerberos KRB5 é aproximadamente equivalente ao uso da autenticação AUTH_SYS. O desempenho diminui significativamente ao usar KRB5P e diminui ligeiramente ao usar KRB5I. O desempenho pode variar dependendo da configuração do cliente e do sistema de arquivos.

Monitoramento e Alarmes

Conhecer rapidamente um problema é importante ao usar a autenticação Kerberos com autorização LDAP. Se a infraestrutura Kerberos ou 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 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 Kerberos, 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 erros do Kerberos:

KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1

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 Necessária do Serviço IAM

O serviço File Storage precisa acessar a senha do servidor LDAP e os segredos do Vault do keytab Kerberos do ponto de acesso NFS para configuração do Kerberos. Tanto o usuário que configura o ponto de acesso NFS quanto o próprio ponto de acesso NFS precisam de acesso de leitura.

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 grupo que está configurando o Kerberos e o LDAP em um ponto de acesso NFS permissões usando uma política como a seguinte:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <Keytab_Secret_ID>, 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. O serviço File Storage apresenta o principal, o número da versão da chave e os tipos de criptografia para o usuário que está configurando o ponto de acesso NFS para validaçã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 controladores de recursos para conceder a um conjunto específico de pontos de acesso NFS o 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 conceda ao grupo dinâmico de pontos de acesso NFS acesso de leitura a segredos do serviço Vault:

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