Conectar clientes NFS

Nesta página, descrevemos como conectar clientes NFS.

Antes de começar

Instale as ferramentas de cliente NFS com base no tipo de distribuição do Linux para preparar o cliente:

RedHat

Execute este comando:

sudo yum install -y nfs-utils

SuSe

Execute este comando:

sudo yum install -y nfs-utils

Debian

Execute este comando:

sudo apt-get install nfs-common

Ubuntu

Execute este comando:

sudo apt-get install nfs-common

Controle de acesso a volumes usando políticas de exportação

O controle de acesso a volumes no NFSv3 e no NFSv4.1 é baseado no endereço IP do cliente. A política de exportação do volume contém até 20 regras de exportação. Cada regra é uma lista separada por vírgulas de IPs ou CIDRs de rede que definem os clientes permitidos para montar o volume. Uma regra também define o tipo de acesso que os clientes têm, como Leitura e gravação ou Somente leitura.

Use as guias a seguir para analisar as políticas com base nas versões do NFS:

NFS sem Kerberos

Todas as versões do NFS sem Kerberos usam o sabor de segurança AUTH_SYS. Nesse modo, é preciso gerenciar as regras de exportação para permitir apenas clientes confiáveis que possam garantir a integridade do ID do usuário e do ID do grupo.

Como medida de segurança, os servidores NFS mapeiam automaticamente as chamadas NFS com UID=0 (raiz) para UID=65534 (anônimo), que tem permissões limitadas no sistema de arquivos. Para mais informações, consulte Compactação de IDs de usuário.

NFSv4.1 com Kerberos

O NFSv4.1 com Kerberos usa políticas de exportação e autenticação adicional com Kerberos para acessar volumes. É possível configurar regras de exportação para aplicar o seguinte:

  • Somente Kerberos (krb5)

  • Assinatura do Kerberos (krb5i)

  • Privacidade do Kerberos (krb5p)

Práticas recomendadas para políticas de exportação

Recomendamos as seguintes práticas recomendadas para políticas de exportação:

  • Ordene as regras de exportação da mais específica para a menos específica.

  • Exporte apenas para os clientes de confiança, como clientes específicos ou CIDRs com os clientes de confiança.

  • Limite o acesso root a um pequeno grupo de clientes de administração confiáveis.

Regra Clientes permitidos Acesso Acesso raiz Descrição
1 10.10.5.3,
10.10.5.9		 Leitura e gravação Ativado Clientes de administração. O usuário raiz permanece raiz e pode gerenciar
todas as permissões de arquivo.
2 10.10.5.0/24 Leitura e gravação Desativado Todos os outros clientes da rede 10.10.5.0/24 podem fazer a montagem,
mas o acesso root é mapeado para "nobody".
3 10.10.6.0/24 Somente leitura Desativado Outra rede pode ler dados do volume, mas
não pode gravar.

Depois que um cliente monta um volume, o acesso no nível do arquivo determina o que um usuário pode fazer. Para mais informações, consulte Controle de acesso no nível do arquivo NFS para volumes no estilo UNIX.

Compactação de User-ID

As políticas de exportação do NFS oferecem controles para compactação de IDs de usuário e grupo, que permite remapear IDs de usuário e grupo para um ID de usuário anônimo por motivos de segurança.

Root squashing

Os servidores NFS melhoram a segurança remapeando o usuário raiz (UID=0) para ninguém (UID=65534), o que torna a raiz um usuário sem privilégios para acesso a arquivos no volume. Esse recurso é conhecido como compactação de raiz. A opção para desativar e manter os privilégios de raiz é chamada de no_root_squash em servidores NFS.

Por padrão, os volumes sem uma política de exportação definida são inacessíveis para endereços IP do cliente. Ao criar uma regra de política de exportação no console Google Cloud , as configurações padrão incluem acesso de leitura e gravação e squash de raiz. A Google Cloud API, a Google Cloud CLI e o Terraform ofereciam suporte ao controle de compactação de raiz usando o parâmetro has-root-access. Embora has-root-access ainda seja aceito, ele foi substituído pelo parâmetro squash-mode.

Como prática recomendada, crie uma regra de exportação dedicada que permita o acesso root para seus hosts de administrador confiáveis e desative o acesso root para outros clientes. Coloque essa regra primeiro, antes de regras mais genéricas.

Compactação de ID de usuário e grupo

O parâmetro squash-mode controla o achatamento de IDs de usuário e de grupo em um UID anônimo, o que pode ser útil para diretórios públicos de caixa de depósito SFTP. Esse parâmetro também substitui o has-root-access e é compatível com a API, a Google Cloud CLI e o Terraform.

O parâmetro squash-mode aceita os seguintes valores:

  • no-root-squash: nesse modo, o usuário raiz permanece raiz e não é remapeado para ninguém (UID=65534).

  • root-squash: essa configuração remapeia o usuário raiz para "nobody".

  • all-squash: essa opção oferece acesso anônimo para todos os usuários, incluindo o root. Todos os usuários são remapeados para o UID e o GID especificados pelo parâmetro anon-uid. Ao usar all-squash, você também precisa especificar anon-uid e definir access-type como READ_WRITE.

Considerações

Considere o seguinte para regras de política de exportação com squash mode:

  • Uma política de exportação é compatível com apenas uma regra all-squash.

  • Quando all-squash está ativado, o usuário raiz é compactado para anônimo. Isso pode ser substituído por uma regra de prioridade mais alta que usa no-root-squash.

  • A replicação de volume não é compatível com volumes que têm uma regra de política de exportação de estilo squash-mode.

  • No nível de serviço Flex, o all-squash não muda automaticamente a propriedade do inode raiz do volume. Para isso, adicione uma regra de exportação no-root-squash, permitindo que o usuário raiz use chown para mudar a propriedade do inode raiz para o UID necessário.

  • O parâmetro has-root-access é aceito. Use has-root-access ou squash-mode, mas não ambos os parâmetros simultaneamente.

Editar um volume

Use as instruções a seguir para atualizar a política de exportação de um volume com squash-mode usando a Google Cloud CLI:

gcloud

Atualize um volume com uma política de exportação usando squash-mode:

gcloud netapp volumes update VOLUME_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --export-policy=access-type=ACCESS_TYPE,squash-mode=SQUASH_MODE,anon-uid=ANON_UID,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES

Substitua as seguintes informações:

  • VOLUME_ID: o ID do volume.

  • PROJECT_ID: o nome do projeto em que o volume está.

  • LOCATION: o local do volume.

  • ACCESS_TYPE: o tipo de acesso precisa ser um de READ_WRITE, READ_ONLY ou READ_NONE.

  • SQUASH_MODE: a regra de exportação precisa ser uma das seguintes opções: NO_ROOT_SQUASH, ROOT_SQUASH ou ALL_SQUASH.

  • ANON_UID: o número de UID a ser compactado.

  • ALLOWED_CLIENTS_IP_ADDRESSES: uma lista de endereços ou intervalos de IP de clientes permitidos, separados por vírgulas.

Os parâmetros de política de exportação podem ser repetidos para incluir várias regras.

O exemplo a seguir mostra onde uma política de exportação tem regras de root-squash e all-squash:

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=allowed-clients=10.0.1.18,nfsv3=true,access-type=READ_WRITE,squash-mode=NO_ROOT_SQUASH \
--export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000

Para mais informações sobre outras flags opcionais, consulte a documentação do SDK Google Cloud sobre a política de exportação de volumes.

Instruções de montagem para clientes NFS

Use as instruções a seguir para receber instruções de montagem para clientes NFS usando o console Google Cloud ou a Google Cloud CLI:

Console

  1. Acesse a página NetApp Volumes no console do Google Cloud .

    Acessar o NetApp Volumes

  2. Clique em Volumes.

  3. Clique em Mostrar mais.

  4. Selecione Instruções de montagem.

  5. Siga as instruções de montagem mostradas no console Google Cloud .

  6. Identifique o comando de montagem e use as opções de montagem, a menos que a carga de trabalho tenha requisitos específicos.

    Somente NFSv3: se o aplicativo não usar bloqueios ou se você não tiver configurado os clientes para ativar a comunicação NSM, recomendamos que você adicione a opção de montagem nolock.

gcloud

Pesquise as instruções de montagem de um volume:

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

Substitua as seguintes informações:

  • VOLUME_NAME: o nome do volume.

  • PROJECT_ID: o nome do projeto em que o volume está.

  • LOCATION: o local do volume.

Para mais informações sobre outras flags opcionais, consulte a documentação do SDK Google Cloud sobre volumes.

Outras instruções do NFSv4.1

Quando você ativa o NFSv4.1 para volumes dos níveis de serviço Flex Unified, Standard, Premium e Extreme, o NFSv4.2 é ativado automaticamente para esses volumes. O comando de ativação do Linux sempre ativa a versão mais recente disponível do NFS, a menos que você especifique a versão a ser ativada. Se quiser montar com o NFSv4.1, use o parâmetro -o vers=4.1 no comando de montagem.

No NFSv3, os usuários e grupos são identificados por IDs de usuário (UID) e IDs de grupo (GID) enviados pelo protocolo NFSv3. É importante garantir que o mesmo UID e GID representem o mesmo usuário e grupo em todos os clientes que acessam o volume. O NFSv4 eliminou a necessidade de mapeamento explícito de UID e GID usando identificadores de segurança. Os identificadores de segurança são strings formatadas como <username|groupname>@<full_qualified_domain>. Um exemplo de identificador de segurança é bob@example.com. O cliente precisa traduzir os UIDs e GIDs usados internamente em um identificador de segurança antes de enviar uma solicitação NFSv4 ao servidor. O servidor precisa traduzir os identificadores de segurança em UIDs e GIDs para uma solicitação recebida e vice-versa para a resposta. A vantagem de usar traduções é que cada cliente e o servidor podem usar UIDs e GIDs internos diferentes. No entanto, a desvantagem é que todos os clientes e o servidor precisam manter uma lista de mapeamento entre UIDs e GIDs, além de nomes de usuários e grupos. As informações de mapeamento nos clientes podem vir de arquivos locais, como /etc/passwd e /etc/groups, ou de um diretório LDAP. A configuração desse mapeamento é gerenciada pelo rpc.idmapd, que precisa ser executado no cliente.

Nos volumes da NetApp, o LDAP precisa fornecer informações de mapeamento, e o Active Directory é o único servidor LDAP compatível com RFC2307bis. Ao usar o Kerberos para NFSv4, o identificador de segurança armazena os principais do Kerberos no formato username@DOMAINNAME, em que DOMAINNAME (em letras maiúsculas) se torna o nome do realm.

IDs numéricos

Para usuários que não querem configurar os mapeamentos de nomes e preferem usar o NFSv4 como substituto do NFSv3, o NFSv4 introduziu uma opção chamada numeric ID, que envia strings de texto codificadas com UID e GID como identificadores de segurança. Isso simplifica o processo de configuração para os usuários.

Você pode verificar a configuração do cliente usando o seguinte comando:

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping

O valor padrão é Y, que ativa os IDs numéricos. O NetApp Volumes aceita o uso de IDs numéricos.

Configurar rpc.idmapd no cliente NFS

Independente do tipo de IDs ou identificadores de segurança que você usa, é necessário configurar rpc.idmapd no cliente NFS. Se você seguiu as instruções de instalação para utilitários de cliente na seção Antes de começar, ele já deve estar instalado, mas talvez não esteja em execução. Algumas distribuições iniciam automaticamente usando systemd quando você monta os primeiros volumes NFS. A configuração mínima necessária para o rpc.idmapd é definir a configuração de domínio. Caso contrário, a raiz do usuário vai aparecer como "nobody" com UID=65534 or 4294967295.

Use as instruções a seguir para configurar rpc.idmapd no cliente NFS:

  1. No cliente, abra o arquivo /etc/idmapd.conf e mude o parâmetro de domínio para um dos seguintes:

    • Se o volume não estiver ativado para LDAP, domain = defaultv4iddomain.com.

    • Se o volume estiver ativado para LDAP, domain = <FDQN_of_Windows_Domain>.

  2. Ative as mudanças em rpc.idmapd executando o seguinte comando:

     nfsidmap -c

Suporte a NFSv4.2

Os níveis de serviço Flex Unified, Standard, Premium e Extreme agora são compatíveis com o protocolo NFSv4.2, além do NFSv4.1, em volumes que já têm o NFSv4.1 ativado.

Ao ativar um volume do NFS, o comando de ativação do Linux seleciona automaticamente a versão mais recente disponível do NFS. A montagem automática de um volume ativado para NFSv4.1 usa o NFSv4.2 por padrão, a menos que a opção de montagem vers=4.1 seja especificada explicitamente.

O NetApp Volumes é compatível com atributos estendidos do NFS xattrs com NFSv4.2. O uso e as limitações de xattrs, conforme detalhado em TR-4962, também são aplicáveis.

Conectar o Linux ao LDAP

Se você estiver usando grupos estendidos do NFSv3 ou NFSv4.1 com identificadores de segurança, configure os NetApp Volumes para usar o Active Directory como servidor LDAP usando um Active Directory anexado a um pool de armazenamento.

Para manter informações de usuário consistentes entre o cliente e o servidor NFS, talvez seja necessário configurar o cliente para usar o Active Directory como serviço de nomes LDAP para informações de usuário e grupo.

Use os seguintes recursos para configurar o LDAP:

Ao usar o NFS Kerberized, talvez seja necessário usar os guias de implantação mencionados nesta seção para configurar o LDAP e garantir a consistência entre o cliente e o servidor.

A seguir

Conecte volumes de grande capacidade com vários endpoints de armazenamento.