Documentação do Oracle Cloud Infrastructure

Usando a Autenticação do Kerberos

O File Storage Service 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.

  • Usuários e serviços em uma rede habilitada 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 File Storage Service suporta autenticação do 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 File Storage Service do Kerberos inclui os recursos a seguir.

criptografia em trânsito

Você pode usar o modo KRB5P do Kerberos, que oferece privacidade de dados, como 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 ou ambientes mistos 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 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 Armazenamento de Arquivos.

Infraestrutura LDAP

O File Storage usa UIDs e GIDs para autorizar o acesso a arquivos. 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 LDAP para autorização.

Se 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 Kerberos pode ser usada sem LDAP, mas todos os principais Kerberos autenticados seriam tratados como anônimos. Para obter mais informações, consulte Pesquisas LDAP e Acesso Anônimo.

Keytab do Kerberos

O keytab Kerberos armazenado no 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 de Internet e VCN padrão, o serviço File Storage cria um FQDN combinando o nome do host do destino de montagem com o FQDN da sub-rede em que o destino de montagem 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 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 OCI File Storage suporta um tamanho máximo de keytab do Kerberos de 1024 bytes.
Importante

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

Quando você valida o keytab do 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 OCI Vault. Certifique-se de selecionar Base64 como o formato do segredo quando colar no keytab convertido.

O File Storage suporta a rotação do keytab usando um keytab de backup. Consulte Rotating Keys 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 File Storage requer infraestrutura LDAP (Lightweight Directory Access Protocol) gerenciada pelo cliente, incluindo um servidor LDAP que suporta um esquema POSIX RFC2307.
  • O File Storage suporta um tamanho máximo de keytab do Kerberos de 1024 bytes.

  • 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, eles poderão ser reduzidos para 256 KB pelo 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 um pouco ao usar KRB5I. O desempenho pode variar dependendo da configuração do cliente e do sistema de arquivos.

Monitoramento e Alarmes

Tornar-se ciente de um problema rapidamente é 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 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 Obrigatória do Serviço IAM

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

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 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 File Storage que leem os segredos do Vault e exibam partes do segredo para validação. O File Storage apresenta o principal, o número da versão da chave e os tipos de criptografia ao usuário 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 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>