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 las plataformas zonales, regionales y los niveles de servicio 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 de clientes y servidores.

Cada protocolo es más adecuado para casos de uso específicos. En la siguiente tabla, se compara 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 autenticación RPCSEC_GSS, implementada con LDAP y Kerberos, que están disponibles en el servicio administrado para Microsoft Active Directory.
Admite Listas de control de acceso (LCA) a archivos o directorios. No Sí. Admite hasta 50 entradas de control de acceso (ACE) por lista.
Grupos de asistencia Hasta 16 grupos Compatibilidad ilimitada con grupos cuando te conectas a Microsoft AD administrado.
Configuración 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 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 retenciones. 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.
  • Carece de autenticación y encriptación de cliente y servidor.
  • Carece de 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.

  • Compatibilidad con 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, el archivo no se puede a las que accede otro cliente, como un nodo de GKE nuevo.

  • 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. Se puede reanudar el estado del cliente y del servidor en la sesión anterior 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 conectados. tienen más proximidad.

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

  • Automatiza el identificador único (UID) y el usuario del identificador único global (GUID) la asignación.

  • Los usuarios y grupos pueden crearse o migrarse a Microsoft AD administrado.

  • Los administradores pueden crear una relación de confianza del dominio con la infraestructura local actual autoadministrado, Active Directory (AD) y dominio LDAP. 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 LCA admite hasta 50 ACE. Se reservan seis entradas para las métricas ACE creados por operaciones del cliente chmod. Estos ACE pueden modificarse después de de la creación de cuentas de servicio.

    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 OWNER@
    • DENY and ALLOW ACEs para 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 verificar el acceso requerido solo en Modo POSIX RWX (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 acceso directo y activa automáticamente todas las marcas correspondientes.

  • La nfs4_getfacl no realiza ninguna traducción del principal por su cuenta. La utilidad nfs4_getfacl mostrará los UID y GUID numéricos para los principales. Como resultado, las principales especiales de OWNER@, GROUP@ y Se mostrará 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, el La instancia de Filestore tendrá el ID nobody de forma predeterminada.

  • Cuando especifiques permisos de escritura para un archivo, o incluso 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 LCA 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. Contrario a otras implementaciones de NFSv4.1, Filestore no hará automáticamente replicar ACES heredado con el propósito de distinguir entre y de solo heredar.

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 configurado, no borres Microsoft AD administrado ni el intercambio de tráfico entre redes. Si lo haces, no se podrá acceder al recurso compartido de Filestore mientras esté activado en un cliente, lo que hace que tus datos sean inaccesibles. Google Cloud no es responsable de interrupciones causadas por acciones del administrador o del usuario.

  • Al usar cualquiera de los parámetros de configuración de seguridad de Kerberos autenticados, los usuarios pueden esperar algunas operaciones de latencia. Las tasas de latencia varían según el nivel de servicio el parámetro de configuración de seguridad especificado. La latencia aumenta con cada aumento de seguridad a nivel de organización.

  • 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.

  • Carece de compatibilidad 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 de origen.

¿Qué sigue?