Información acerca de los protocolos de sistemas de archivos compatibles

Filestore admite los siguientes protocolos de sistemas de archivos:

NFSv3

  • Disponible en todos los niveles de servicio.
  • Admite la comunicación bidireccional entre el cliente y el servidor.
    • Usa varios puertos.
    • Crea un canal de confianza para el tráfico y las operaciones de red.
  • Ofrece una configuración rápida para el acceso estándar a POSIX.

NFSv4.1

  • Disponible en niveles de servicio zonales, regionales y empresariales.
  • Es compatible con las configuraciones de firewall modernas y admite los requisitos de cumplimiento de seguridad de la red.
    • El cliente siempre inicia la comunicación y siempre se entrega a través de un solo puerto de servidor, 2049.
    • Admite la autenticación del cliente y del servidor.

Cada protocolo es más adecuado para casos de uso específicos. En la siguiente tabla, se comparan las especificaciones de cada protocolo:

Especificación NFSv3 NFSv4.1
Niveles de servicio admitidos Todos los niveles de servicio Zonal, regional y empresarial
Comunicación bidireccional Sí No. El cliente siempre inicia la comunicación con el puerto del servidor 2049.
Autenticación No Sí. Requiere la autenticación RPCSEC_GSS, implementada con LDAP y Kerberos, ambos disponibles en el Servicio administrado para Microsoft Active Directory.
Admite listas de control de acceso (LCA) de archivos o directorios. No Sí. Admite hasta 50 entradas de control de acceso (ACE) por lista.
Compatibilidad con Grupos Hasta 16 grupos Admite grupos ilimitados cuando se conecta a Microsoft AD administrado.
Configuración de seguridad sys: Crea un canal de confianza. sys: Crea un canal de confianza. krb5. Autentica al cliente y al servidor. krb5i. Proporciona autenticación y verificaciones de integridad de los mensajes.krb5p. Proporciona autenticación, verificaciones de integridad de los mensajes y encriptación de datos en tránsito.
Latencia de las operaciones Ninguno La latencia de las operaciones aumenta con el nivel de seguridad seleccionado.
Tipo de recuperación Sin estado Con estado
Tipo de bloqueo de archivos Administrador de bloqueo de red (NLM). El cliente controla la cerradura. Bloqueo de aviso basado en el arrendamiento El servidor controla el bloqueo.
Admite fallas del cliente No Sí
Admite el acceso privado a servicios No No

Beneficios de NFSv3

El protocolo NFSv3 ofrece una configuración rápida para el acceso estándar a POSIX.

Limitaciones de NFSv3

La siguiente es una lista de las limitaciones de NFSv3:

  • No es compatible con el acceso privado a servicios.
  • No tiene autenticación ni encriptación de cliente y servidor.
  • Falta el manejo de fallas del cliente.

Beneficios de NFSv4.1

El protocolo NFSv4.1 usa el método de autenticación RPCSEC_GSS, que se implementa con LDAP y Kerberos para proporcionar autenticación de cliente y servidor, verificaciones de integridad de mensajes y encriptación de datos en tránsito.

Estas capacidades de seguridad hacen que el protocolo NFSv4.1 sea compatible con los requisitos modernos de cumplimiento de seguridad de la red:

  • Usa un solo puerto de servidor, 2049, para toda la comunicación, lo que ayuda a simplificar la configuración del firewall.

  • Admite listas de control de acceso (LCA) de archivos NFSv4.1.

    • Cada LCA admite hasta 50 entradas de control de acceso (ACE) por archivo o directorio. Esto incluye los registros de herencia.

  • Se admiten grupos ilimitados cuando se usa la integración de Microsoft AD administrado.

  • Admite un mejor manejo de fallas del cliente con bloqueos de asesoramiento basados en arrendamientos.

    • El cliente debe verificar la conexión continua con el servidor. Si el cliente no renueva el arrendamiento, el servidor libera el bloqueo y el archivo estará disponible para cualquier otro cliente que solicite acceso a través de un arrendamiento de bloqueo. En NFSv3, si se borra un cliente mientras está bloqueado, otro cliente, como un nuevo nodo de GKE, no puede acceder al archivo.

  • Admite la recuperación con estado.

    • A diferencia de NFSv3, NFSv4.1 es un protocolo con estado basado en TCP y en la conexión. El estado del cliente y el servidor en la sesión anterior se puede reanudar después de la recuperación.

Servicio administrado para Microsoft Active Directory

Si bien el Servicio administrado para Microsoft Active Directory (Microsoft AD administrado) no es un requisito estricto, es la única solución administrada por Google Cloud que admite LDAP y Kerberos, ambos requisitos para el protocolo NFSv4.1 de Filestore.

Se recomienda a los administradores que usen el Servicio administrado para Microsoft Active Directory (Microsoft AD administrado) para implementar y administrar LDAP y Kerberos.

Como solución administrada por Google Cloud, Microsoft AD administrado proporciona los siguientes beneficios:

  • Ofrece una implementación multirregión que admite hasta cinco regiones en el mismo dominio.

    • Reduce la latencia, ya que garantiza que los usuarios y sus respectivos servidores de acceso estén más cerca.

  • Admite POSIX RFC 2307 y RFC 2307bis, requisitos para la implementación de NFSv4.1.

  • Automatiza la asignación de usuarios de identificador único (UID) y de identificador único a nivel global (GUID).

  • Los usuarios y los grupos se pueden crear en Microsoft AD administrado o migrar a él.

  • Los administradores pueden crear una confianza de dominio con el dominio de Active Directory (AD) y LDAP local y autoadministrado actual. Con esta opción, no es necesaria la migración.

  • Proporciona un ANS.

Control de acceso y comportamientos adicionales

  • Los ACE de NFSv4.1 de Filestore se administran en Linux con los siguientes comandos:

    • nfs4_setfacl: Crea o edita ACE en un archivo o directorio.
    • nfs4_getfacl: Muestra una lista de los ACE en un archivo o directorio.

  • Cada ACL admite hasta 50 ACE. Se reservan seis entradas para los ACE generados automáticamente que crean las operaciones chmod del cliente. Estos ACE se pueden modificar después de su creación.

    Los registros ACE generados automáticamente que representan los bits de modo se enumeran en el siguiente orden de prioridad:

    • DENY and ALLOW ACEs para el OWNER@
    • DENY and ALLOW ACEs para el GROUP@

    • DENY and ALLOW ACEs para EVERYONE@

      Si ya están presentes, se volverán a usar y modificar según los nuevos bits de modo aplicados.

  • Filestore NFSv4.1 admite la verificación del acceso requerido solo en el modo RWX de POSIX (lectura, escritura y ejecución). No diferenciará entre las operaciones write append y write que modifican el contenido o la especificación SETATTR. La utilidad nfs4_setfacl también acepta RWX como un atajo y activa automáticamente todas las marcas adecuadas.

  • nfs4_getfacl no realiza ninguna traducción del principal por sí solo. La utilidad nfs4_getfacl mostrará los UID y GUID numéricos para los principales. Como resultado, se mostrarán los principales especiales de OWNER@, GROUP@ y EVERYONE@.

  • Independientemente de si usas Microsoft AD administrado, cuando trabajes con AUTH-SYS y la utilidad nfs4_setfacl, los administradores deben especificar los UID y GUID numéricos, no los nombres de usuario. Esta utilidad no puede traducir nombres a estos valores. Si no se proporciona correctamente, la instancia de Filestore usará el ID nobody de forma predeterminada.

  • Cuando especifiques permisos de escritura para un archivo, o incluso para archivos afectados por un ACE heredado, el ACE debe incluir las marcas w (escritura) y a (adición).

  • Cuando se verifican los permisos de SETATTR, la respuesta que se muestra es similar a POSIX de la siguiente manera:

    • El superusuario o el usuario ROOT puede hacer cualquier cosa.
    • Solo el propietario del archivo puede establecer los bits de modo, las ACL y las marcas de tiempo en una hora y un grupo específicos, como uno de los GUID a los que pertenece.
    • Los usuarios que no sean el propietario del archivo pueden ver los atributos, incluida la LCA.

  • Un solo ACE abarca los permisos efectivos y de solo herencia. A diferencia de otras implementaciones de NFSv4.1, Filestore no replicará automáticamente los ACES heredados con el fin de distinguir entre los ACES efectivos y los heredados.

Limitaciones de NFSv4.1

La siguiente es una lista de las limitaciones de NFSv4.1:

  • El protocolo NFSv4.1 no se puede combinar con las siguientes funciones:

  • El protocolo NFSv4.1 no admite AUDIT and ALARM ACEs. Filestore no admite la auditoría de acceso a los datos.

  • Una vez que lo hagas, no borres Managed Microsoft AD ni el intercambio de tráfico de red. De lo contrario, no podrás acceder a los datos compartidos de Filestore mientras estén activados en un cliente. Google Cloud no es responsable de las interrupciones causadas por acciones del administrador o del usuario.

  • Cuando se usa cualquiera de los parámetros de configuración de seguridad de Kerberos autenticados, los usuarios pueden esperar latencia en algunas operaciones. Las tasas de latencia varían según el nivel de servicio y la configuración de seguridad especificada. La latencia aumenta con cada nivel de seguridad.

  • No se admite la auditoría de acceso a los datos.

  • La solución NFSv4.1 de Filestore requiere la autenticación RPCSEC_GSS. Este método de autenticación solo se implementa con LDAP y Kerberos, que están disponibles en Microsoft AD administrado. No se admiten otros mecanismos de autenticación.

  • No es compatible con el acceso privado a servicios.

  • Si deseas que una instancia de Filestore se una a Microsoft AD administrado a través de una VPC compartida, debes usar gcloud o la API de Filestore. No puedes unir la instancia a Microsoft AD administrado con la consola de Google Cloud.

  • El nombre de dominio de Microsoft AD administrado no debe superar los 56 caracteres.

  • Para crear una instancia empresarial, debes ejecutar operaciones directamente a través de la API de Filestore. Para obtener más información, consulta Niveles de servicio.

  • Cuando restableces una copia de seguridad, la instancia nueva debe usar el mismo protocolo que la instancia fuente.

¿Qué sigue?