Sobre os protocolos do sistema de arquivos com suporte

O Filestore é compatível com os seguintes protocolos de sistema de arquivos:

NFSv3

  • Disponível em todos os níveis de serviço.
  • Oferece suporte à comunicação bidirecional entre o cliente e o servidor.
    • Usa várias portas.
    • Cria um canal de confiança para tráfego e operações de rede.
  • Oferece configuração rápida para acesso POSIX padrão.

NFSv4.1

  • Disponível nos níveis de serviço empresarial, regional e por zona.
  • Com suporte do driver CSI do Filestore para criar instâncias zonais ou empresariais e montá-las com semântica NFSv4.1.
  • Compatível com configurações de firewall modernas e compatível com requisitos de conformidade de segurança de rede.
    • A comunicação é sempre iniciada pelo cliente e sempre atendida por uma única porta de servidor, 2049.
    • Suporta autenticação de cliente e servidor.

Cada protocolo é mais adequado para casos de uso específicos. A tabela a seguir compara as especificações de cada protocolo:

Especificação NFSv3 NFSv4.1
Níveis de serviço compatíveis Todos os níveis de serviço Zonal, regional e empresarial
Comunicação bidirecional Sim Não. A comunicação é sempre iniciada pelo cliente usando a porta do servidor 2049.
Autenticação Não Sim. Exige a autenticação RPCSEC_GSS, implementada usando LDAP e Kerberos, ambos disponíveis no Serviço gerenciado para o Microsoft Active Directory.
Compatível com listas de controle de acesso (ACLs) de arquivos ou diretórios Não Sim. Aceita até 50 entradas de controle de acesso (ACEs) por lista.
Suporte do Grupos Até 16 grupos Suporte a grupos ilimitados quando conectados ao Microsoft AD gerenciado.
Configuração de segurança sys. Cria um canal de confiança. sys. Cria um canal de confiança. krb5. Autentica o cliente e o servidor. krb5i. Fornece autenticação e verificações de integridade de mensagens.krb5p. Oferece autenticação, verificações de integridade de mensagens e criptografia de dados em trânsito.
Latência de operações Nenhum A latência das operações aumenta com o nível de segurança selecionado.
Tipo de recuperação Sem estado Com estado
Tipo de bloqueio de arquivo Network Lock Manager (NLM). O bloqueio é controlado pelo cliente. Bloqueio consultivo baseado em concessão. O bloqueio é controlado pelo servidor.
Suporta falhas do cliente Não Sim
Suporte ao acesso privado a serviços Sim Sim
Compatível com o Private Service Connect (GA na lista de permissões) Não Sim

Benefícios do NFSv3

O protocolo NFSv3 oferece configuração rápida para acesso POSIX padrão.

Limitações do NFSv3

Confira abaixo uma lista de limitações do NFSv3:

  • Não tem autenticação e criptografia de cliente e servidor.
  • Não há tratamento de falhas do cliente.

Benefícios do NFSv4.1

O protocolo NFSv4.1 usa o método RPCSEC_GSS Authentication, que é implementado usando LDAP e Kerberos para fornecer autenticação de cliente e servidor, verificações de integridade de mensagens e criptografia de dados em trânsito.

Essas funcionalidades de segurança tornam o protocolo NFSv4.1 compatível com os requisitos modernos de compliance de segurança de rede:

  • Usa uma única porta de servidor, 2049, para toda a comunicação, ajudando a simplificar as configurações de firewall.

  • Compatível com listas de controle de acesso (ACLs) de arquivos NFSv4.1.

    • Cada ACL aceita até 50 entradas de controle de acesso (ACEs) por arquivo ou diretório. Isso inclui registros de herança.
  • Suporte a grupos ilimitados ao usar a integração do Managed Microsoft AD.

  • Oferece melhor tratamento de falhas do cliente com bloqueio consultivo baseado em concessão.

    • O cliente precisa verificar a conexão contínua com o servidor. Se o cliente não renovar o contrato, o servidor vai liberar o bloqueio, e o arquivo ficará disponível para qualquer outro cliente que solicitar acesso por um contrato de bloqueio. No NFSv3, se um cliente for excluído enquanto estiver bloqueado, o arquivo não poderá ser acessado por outro cliente, como um novo nó do GKE.
  • Oferece suporte à recuperação com estado.

    • Ao contrário do NFSv3, o NFSv4.1 é um protocolo com estado baseado em TCP e conexão. O estado do cliente e do servidor na sessão anterior pode ser retomado após a recuperação.

Serviço gerenciado para Microsoft Active Directory

Embora o Serviço gerenciado para Microsoft Active Directory (Microsoft AD gerenciado) não seja um requisito estrito, ele é a única solução gerenciada pelo Google Cloud que oferece suporte a LDAP e Kerberos, ambos requisitos do protocolo NFSv4.1 do Filestore.

Recomendamos que os administradores usem o Serviço gerenciado para Microsoft Active Directory (Managed Microsoft AD) para implementar e gerenciar LDAP e Kerberos.

Como uma solução gerenciada pelo Google Cloud, o Managed Microsoft AD oferece os seguintes benefícios:

  • Oferece implantação multirregional, com suporte para até cinco regiões no mesmo domínio.

    • Reduz a latência, garantindo que os usuários e os respectivos servidores de login estejam mais próximos.
  • Oferece suporte a POSIX RFC 2307 e RFC 2307bis, requisitos para implementação do NFSv4.1.

  • Automatiza o mapeamento de usuários com identificadores exclusivos (UIDs) e identificadores exclusivos globais (GUIDs).

  • Os usuários e grupos podem ser criados ou migrados para o Microsoft AD gerenciado.

  • Os administradores podem criar uma relação de confiança com o domínio atual do Active Directory (AD) e do LDAP local e autogerenciado. Com essa opção, a migração não é necessária.

  • Fornece um SLA.

Controle de acesso e comportamentos adicionais

  • As ACEs NFSv4.1 do Filestore são gerenciadas no Linux usando os seguintes comandos:

    • nfs4_setfacl: crie ou edite ACEs em um arquivo ou diretório.
    • nfs4_getfacl: lista as ACEs em um arquivo ou diretório.
  • Cada ACL aceita até 50 ACEs. Seis entradas são reservadas para ACEs geradas automaticamente criadas por operações do cliente chmod. Essas ACEs podem ser modificadas após a criação.

    Os registros ACE gerados automaticamente que representam os bits de modo são listados na seguinte ordem de prioridade:

    • DENY and ALLOW ACEs para o OWNER@
    • DENY and ALLOW ACEs para o GROUP@
    • DENY and ALLOW ACEs para EVERYONE@

      Se esses ACEs já estiverem presentes, eles serão reutilizados e modificados de acordo com os novos bits do modo aplicado.

  • O NFSv4.1 do Filestore oferece suporte à verificação do acesso necessário apenas no modo POSIX RWX (leitura, gravação e execução). Ele não diferencia entre operações de write append e write que modificam o conteúdo ou a especificação de SETATTR. O utilitário nfs4_setfacl também aceita RWX como um atalho e ativa automaticamente todas as flags adequadas.

  • O nfs4_getfacl não faz nenhuma tradução do principal por conta própria. O utilitário nfs4_getfacl vai mostrar o UID e o GUID numéricos para os principais. Como resultado, os principais especiais de OWNER@, GROUP@ e EVERYONE@ serão mostrados.

  • Ao trabalhar com AUTH-SYS e o utilitário nfs4_setfacl, os administradores precisam especificar os UID e GUID numéricos, não os nomes de usuário, seja qual for o uso do Microsoft AD gerenciado. Ela não consegue traduzir nomes para esses valores. Se não for fornecido corretamente, a instância do Filestore vai usar o ID nobody por padrão.

  • Ao especificar permissões de gravação para um arquivo ou até mesmo arquivos afetados por uma ACE herdada, a ACE precisa incluir as flags w (gravação) e a (adição).

  • Ao verificar as permissões de SETATTR, a resposta retornada é semelhante a POSIX da seguinte maneira:

    • O superusuário ou usuário ROOT pode fazer qualquer coisa.
    • Somente o proprietário do arquivo pode definir os bits de modo, as ACLs e os carimbos de data/hora para um horário e grupo específicos, como um dos GUIDs a que ele pertence.
    • Outros usuários que não são proprietários do arquivo podem ver os atributos, incluindo a ACL.
  • Uma única ACE abrange permissões efetivas e somente de herança. Ao contrário de outras implementações do NFSv4.1, o Filestore não replica automaticamente as ACEs herdadas para distinguir entre as ACEs efetivas e somente de herança.

Limitações do NFSv4.1

Confira abaixo uma lista de limitações do NFSv4.1:

  • O protocolo NFSv4.1 não pode ser combinado com os compartilhamentos múltiplos do Filestore para GKE.

  • O protocolo NFSv4.1 não é compatível com AUDIT and ALARM ACEs. O Filestore não é compatível com a auditoria de acesso a dados.

  • Depois de configurado, não exclua o Managed Microsoft AD e o peering de rede. Isso faz com que o compartilhamento do Filestore fique inacessível enquanto estiver montado em um cliente, tornando seus dados inacessíveis. Google Cloud não é responsável por interrupções causadas por ações de administradores ou usuários.

  • Ao usar qualquer uma das configurações de segurança autenticadas do Kerberos, os usuários podem esperar alguma latência nas operações. As taxas de latência variam de acordo com o nível de serviço e a configuração de segurança especificada. A latência aumenta com cada nível de segurança.

  • A auditoria de acesso a dados não é compatível.

  • A solução NFSv4.1 do Filestore usa a autenticação RPCSEC_GSS, que é implementada usando LDAP e Kerberos, ambos disponíveis no Managed Microsoft AD. O Filestore NFSv4.1 também pode ser usado sem mecanismos de autenticação, assim como o NFSv3. Outros mecanismos de autenticação não são compatíveis.

  • Se você quiser que uma instância do Filestore participe do Managed Microsoft AD por uma VPC compartilhada, use gcloud ou a API do Filestore. Não é possível adicionar a instância ao Microsoft AD gerenciado usando o consoleGoogle Cloud .

  • O nome do domínio do Microsoft AD gerenciado não pode exceder 56 caracteres.

  • Para criar uma instância empresarial, execute operações diretamente pela API Filestore. Para mais informações, consulte Níveis de serviço.

  • Ao restaurar um backup, a nova instância precisa usar o mesmo protocolo da instância de origem.

A seguir