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 la red.
  • Ofrece una configuración rápida para el acceso POSIX estándar.

NFSv4.1

  • Disponible en los niveles de servicio de zona, regional y de empresa.
  • Compatible con las configuraciones de firewall modernas y con los requisitos de cumplimiento de seguridad de red.
    • La comunicación siempre la inicia el cliente y siempre se sirve a través de un único puerto de servidor, 2049.
    • Admite la autenticación de clientes y servidores.

Cada protocolo se adapta mejor a casos prácticos específicos. En la siguiente tabla se comparan las especificaciones de cada protocolo:

Especificaciones NFSv3 NFSv4.1
Niveles de servicio admitidos Todos los niveles de servicio Zonales, regionales y empresariales
Comunicación bidireccional No. La comunicación siempre la inicia el cliente mediante el puerto del servidor 2049.
Autenticación No Sí. Requiere la autenticación RPCSEC_GSS, implementada mediante LDAP y Kerberos, ambos disponibles en Managed Service for Microsoft Active Directory.
Admite listas de control de acceso (LCAs) de archivos o directorios No Sí. Admite hasta 50 entradas de control de acceso (ACEs) por lista.
Asistencia de Grupos Hasta 16 grupos Admite un número ilimitado de grupos cuando se conecta a Microsoft AD gestionado.
Ajuste de seguridad sys. Crea un canal de confianza. sys. Crea un canal de confianza. krb5. Autentica el cliente y el servidor. krb5i. Proporciona autenticación y comprobaciones de integridad de los mensajes.krb5p. Proporciona autenticación, comprobaciones de integridad de los mensajes y cifrado de los 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 Apatrida Con reconocimiento del estado
Tipo de bloqueo de archivos Gestor de bloqueos de red (NLM). El bloqueo lo controla el cliente. Bloqueo de asesoramiento basado en arrendamientos. El bloqueo lo controla el servidor.
Admite errores del cliente No
Admite el acceso privado a servicios
Admite Private Service Connect (disponibilidad general en la lista de permitidos) No

Ventajas de NFSv3

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

Limitaciones de NFSv3

A continuación se muestra una lista de las limitaciones de NFSv3:

  • No tiene autenticación ni cifrado de cliente y servidor.
  • No gestiona los errores del cliente.

Ventajas de NFSv4.1

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

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

  • Usa un solo puerto de servidor, 2049, para todas las comunicaciones, lo que ayuda a simplificar las configuraciones del cortafuegos.

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

    • Cada LCA admite hasta 50 entradas de control de acceso (ECA) por archivo o directorio. Esto incluye los registros de herencia.
  • Admite un número ilimitado de grupos al usar la integración de Microsoft AD gestionado.

  • Mejora la gestión de errores del cliente con el bloqueo de asesoramiento basado en concesiones.

    • El cliente debe verificar que la conexión con el servidor continúa. Si el cliente no renueva el bloqueo, el servidor lo libera y el archivo estará disponible para cualquier otro cliente que solicite acceso mediante un bloqueo. En NFSv3, si se elimina un cliente mientras está bloqueado, otro cliente, como un nuevo nodo de GKE, no podrá acceder al archivo.
  • Admite la recuperación con reconocimiento del estado.

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

Servicio gestionado de Microsoft Active Directory

Aunque Managed Service for Microsoft Active Directory (Managed Microsoft AD) no es un requisito estricto, es la única solución gestionada por Google Cloudque admite LDAP y Kerberos, ambos requisitos del protocolo NFSv4.1 de Filestore.

Recomendamos encarecidamente a los administradores que utilicen el servicio gestionado de Microsoft Active Directory (Microsoft AD gestionado) para implementar y gestionar LDAP y Kerberos.

Como solución gestionada, Microsoft AD gestionado ofrece las siguientes ventajas: Google Cloud

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

    • Reduce la latencia al asegurarse de que los usuarios y sus respectivos servidores de inicio de sesión 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 identificadores únicos (UID) e identificadores únicos globales (GUID) a los usuarios.

  • Los usuarios y los grupos se pueden crear o migrar a Managed Microsoft AD.

  • Los administradores pueden crear una relación de confianza de dominio con el dominio de Active Directory (AD) y LDAP local, autogestionado y actual. Con esta opción, no es necesario realizar ninguna migración.

  • Proporciona un SLA.

Control de acceso y comportamientos adicionales

  • Los ACEs de NFSv4.1 de Filestore se gestionan en Linux con los siguientes comandos:

    • nfs4_setfacl: crea o edita ACEs en un archivo o directorio.
    • nfs4_getfacl: muestra las ACEs de un archivo o directorio.
  • Cada ACL admite hasta 50 ACEs. Se reservan seis entradas para los ACEs autogenerados creados por las operaciones del cliente chmod. Estas ACEs se pueden modificar después de la creación.

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

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

      Si ya existen ACEs de este tipo, se reutilizarán y se modificarán según los nuevos bits del modo aplicado.

  • Filestore NFSv4.1 solo admite la comprobación del acceso necesario en el modo POSIX RWX (lectura, escritura y ejecución). No distinguirá entre las operaciones write append y write que modifiquen el contenido o la especificación SETATTR. La utilidad nfs4_setfacl también acepta RWX como acceso directo y activa automáticamente todas las marcas correspondientes.

  • El nfs4_getfacl no traduce la entidad principal por sí solo. La utilidad nfs4_getfacl mostrará los valores numéricos UID y GUID de los principales. Como resultado, se mostrarán los principales especiales de OWNER@, GROUP@ y EVERYONE@.

  • Independientemente de si se usa Microsoft AD gestionado, al trabajar con AUTH-SYS y la utilidad nfs4_setfacl, los administradores deben especificar los valores numéricos UID y GUID, 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.

  • Al especificar permisos de escritura para un archivo o incluso para archivos afectados por una ACE heredada, la ACE debe incluir tanto la marca w (escritura) como la a (añadir).

  • Al comprobar los permisos de SETATTR, la respuesta devuelta es similar a la de POSIX de la siguiente manera:

    • El superusuario o el usuario ROOT puede hacer cualquier cosa.
    • Solo el propietario del archivo puede definir los bits de modo, las ACLs y las marcas de tiempo en un momento 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 único ACE abarca tanto los permisos efectivos como los de solo herencia. A diferencia de otras implementaciones de NFSv4.1, Filestore no replicará automáticamente los ACEs heredados para distinguir entre los ACEs efectivos y los ACEs de solo herencia.

Limitaciones de NFSv4.1

A continuación se muestra 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 datos.

  • Una vez configurados, no elimine Microsoft AD gestionado ni el peering de redes. Si lo hace, la partición de Filestore no estará accesible mientras esté montada en un cliente, por lo que no podrá acceder a sus datos. Google Cloud no se hace responsable de las interrupciones causadas por las acciones de administradores o usuarios.

  • Cuando se usa cualquiera de los ajustes de seguridad de Kerberos autenticados, los usuarios pueden esperar cierta latencia en las operaciones. Las latencias varían según el nivel de servicio y la configuración de seguridad especificados. La latencia aumenta con cada nivel de seguridad.

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

  • La solución NFSv4.1 de Filestore usa la autenticación RPCSEC_GSS, que se implementa mediante LDAP y Kerberos, ambos disponibles en Managed Microsoft AD. Filestore NFSv4.1 también se puede usar sin ningún mecanismo de autenticación, de forma similar a NFSv3. No se admiten otros mecanismos de autenticación.

  • Si quieres que una instancia de Filestore se una a Managed Microsoft AD a través de una VPC compartida, debes usar gcloud o la API de Filestore. No puedes unir la instancia a Microsoft AD gestionado mediante la consolaGoogle Cloud .

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

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

  • Al restaurar una copia de seguridad, la nueva instancia debe usar el mismo protocolo que la instancia de origen.

Siguientes pasos