Acerca dos protocolos do sistema de ficheiros suportados

O Filestore suporta os seguintes protocolos de sistema de ficheiros:

NFSv3

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

NFSv4.1

  • Disponível nos níveis de serviço zonais, regionais e empresariais.
  • Compatível com configurações de firewall modernas e suporta os requisitos de conformidade de segurança de rede.
    • A comunicação é sempre iniciada pelo cliente e sempre publicada através de uma única porta do servidor, 2049.
    • Suporta a autenticação de cliente e servidor.

Cada protocolo é mais adequado para exemplos de utilização específicos. A tabela seguinte compara as especificações de cada protocolo:

Especificação NFSv3 NFSv4.1
Níveis de serviços suportados Todos os níveis de serviços Zonal, regional e empresarial
Comunicação bidirecional Sim Não. A comunicação é sempre iniciada pelo cliente através da porta do servidor 2049.
Autenticação Não Sim. Requer a autenticação RPCSEC_GSS, implementada através do LDAP e do Kerberos, ambos disponíveis no serviço gerido para o Microsoft Active Directory.
Suporta listas de controlo de acesso (LCAs) de ficheiros ou diretórios Não Sim. Suporta até 50 entradas de controlo de acesso (ACEs) por lista.
Apoio técnico do Grupos Até 16 grupos Suporte de grupos ilimitado quando ligado ao Microsoft AD gerido.
Definiçã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 verificações de autenticação e integridade das mensagens.krb5p. Fornece autenticação, verificações de integridade das mensagens e encriptação de dados em trânsito.
Latência das 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 ficheiros Network Lock Manager (NLM). O bloqueio é controlado pelo cliente. Bloqueio de aconselhamento baseado em concessão. O bloqueio é controlado pelo servidor.
Suporta falhas do cliente Não Sim
Suporta o acesso a serviços privados Sim Sim
Suporta o Private Service Connect (GA na lista de autorizações) Não Sim

Vantagens do NFSv3

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

Limitações do NFSv3

Segue-se uma lista de limitações do NFSv3:

  • Não tem autenticação nem encriptação de cliente e servidor.
  • Não tem processamento de falhas do cliente.

Vantagens do NFSv4.1

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

Estas capacidades de segurança tornam o protocolo NFSv4.1 compatível com os requisitos de conformidade de segurança de rede modernos:

  • Usa uma única porta do servidor, 2049, para todas as comunicações, o que ajuda a simplificar as configurações da firewall.

  • Suporta listas de controlo de acesso (ACLs) a ficheiros NFSv4.1.

    • Cada LCA suporta até 50 entradas de controlo de acesso (ECAs) por ficheiro ou diretório. Isto inclui registos de herança.

  • Suporte de grupos ilimitados quando usa a integração do Microsoft AD gerido.

  • Suporta um melhor processamento de falhas do cliente com o bloqueio consultivo baseado em concessão.

    • O cliente tem de validar a ligação contínua com o servidor. Se o cliente não renovar a concessão, o servidor liberta o bloqueio e o ficheiro fica disponível para qualquer outro cliente que solicite acesso através de uma concessão de bloqueio. No NFSv3, se um cliente for eliminado enquanto estiver bloqueado, o ficheiro não pode ser acedido por outro cliente, como um novo nó do GKE.

  • Suporta a recuperação com estado.

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

Serviço gerido para o Microsoft Active Directory

Embora o Serviço gerido para o Microsoft Active Directory (Microsoft AD gerido) não seja um requisito rigoroso, é a única solução Google Cloudgerida para suportar o LDAP e o Kerberos, que são requisitos para o protocolo NFSv4.1 do Filestore.

Recomendamos vivamente que os administradores usem o Serviço gerido para o Microsoft Active Directory (Microsoft AD gerido) para implementar e gerir o LDAP e o Kerberos.

Como uma solução gerida pela Google, o Microsoft AD gerido oferece as seguintes vantagens: Google Cloud

  • Oferece implementação em várias regiões, suportando até cinco regiões no mesmo domínio.

    • Reduz a latência garantindo que os utilizadores e os respetivos servidores de início de sessão estão mais próximos.

  • Suporta POSIX RFC 2307 e RFC 2307bis, requisitos para a implementação do NFSv4.1.

  • Automatiza o mapeamento de utilizadores com identificadores únicos (UID) e identificadores únicos globais (GUID).

  • Os utilizadores e os grupos podem ser criados ou migrados para o Managed Microsoft AD.

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

  • Fornece um SLA.

Controlo de acesso e comportamentos adicionais

  • As ACEs NFSv4.1 do Filestore são geridas no Linux através dos seguintes comandos:

    • nfs4_setfacl: criar ou editar ACEs num ficheiro ou num diretório.
    • nfs4_getfacl: listar as ACEs num ficheiro ou num diretório.

  • Cada ACL suporta até 50 ACEs. Seis entradas estão reservadas para ACEs gerados automaticamente criados por operações do cliente chmod. Estas ACEs podem ser modificadas após a criação.

    Os registos ACE gerados automaticamente que representam os bits de modo são apresentados 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 já existirem ACEs, estes são reutilizados e modificados de acordo com os novos bits do modo aplicado.

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

  • O nfs4_getfacl não traduz o principal por si só. O utilitário nfs4_getfacl mostra os valores numéricos UID e GUID para os principais. Como resultado, são apresentados os principais especiais de OWNER@, GROUP@ e EVERYONE@.

  • Independentemente de usar o Microsoft AD gerido, quando trabalhar com o AUTH-SYS e o utilitário nfs4_setfacl, os administradores têm de especificar o UID numérico e o GUID, não os nomes de utilizadores. Esta utilidade não consegue traduzir nomes para estes valores. Se não for fornecido corretamente, a instância do Filestore vai usar o ID nobody por predefinição.

  • Quando especificar autorizações de escrita para um ficheiro ou mesmo ficheiros afetados por um ACE herdado, o ACE tem de incluir os flags w (escrita) e a (anexar).

  • Quando verifica as autorizações para SETATTR, a resposta devolvida é semelhante a POSIX da seguinte forma:

    • O superutilizador ou o utilizador ROOT pode fazer tudo.
    • Apenas o proprietário do ficheiro pode definir os bits de modo, as ACLs e as datas/horas para uma hora e um grupo específicos, como um dos GUIDs a que pertence.
    • Os utilizadores que não sejam o proprietário do ficheiro podem ver os atributos, incluindo a LCA.

  • Uma única ACE abrange as autorizações efetivas e apenas de herança. Ao contrário de outras implementações do NFSv4.1, o Filestore não replica automaticamente os ACEs herdados para distinguir entre ACEs eficazes e apenas herdados.

Limitações do NFSv4.1

Segue-se uma lista de limitações do NFSv4.1:

  • Não é possível combinar o protocolo NFSv4.1 com as seguintes funcionalidades:

  • O protocolo NFSv4.1 não suporta AUDIT and ALARM ACEs. O Filestore não suporta a auditoria de acesso a dados.

  • Depois de configurado, não elimine o Managed Microsoft AD nem a interligação de redes. Se o fizer, a partilha do Filestore fica inacessível enquanto estiver montada num cliente, o que torna os seus dados inacessíveis. Google Cloud não é responsável por indisponibilidades causadas por ações do administrador ou do utilizador.

  • Quando usam qualquer uma das definições de segurança Kerberos autenticadas, os utilizadores podem esperar alguma latência nas operações. As taxas de latência variam consoante o nível de serviço e a definição de segurança especificados. A latência aumenta com cada nível de segurança crescente.

  • A auditoria de acesso a dados não é suportada.

  • A solução NFSv4.1 do Filestore usa a autenticação RPCSEC_GSS, que é implementada através do LDAP e do Kerberos, ambos disponíveis no Microsoft AD gerido. O Filestore NFSv4.1 também pode ser usado sem mecanismos de autenticação, de forma semelhante ao NFSv3. Não são suportados outros mecanismos de autenticação.

  • Se quiser que uma instância do Filestore se junte ao Managed Microsoft AD através de uma VPC partilhada, tem de usar o comando gcloud ou a API Filestore. Não pode associar a instância ao Managed Microsoft AD através da Google Cloud consola.

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

  • Para criar uma instância empresarial, tem de executar operações diretamente através da API Filestore. Para mais informações, consulte os níveis de serviço.

  • Quando restaurar uma cópia de segurança, a nova instância tem de usar o mesmo protocolo que a instância de origem.

O que se segue?