Control de acceso

En esta página se describe cómo controlar el acceso a las instancias de Filestore.

  • Con el protocolo NFSv4.1, puedes usar Kerberos para proteger el acceso a las instancias de Filestore. Para obtener más información, consulta Acerca de los protocolos compatibles.

  • Como alternativa, puedes usar las opciones de Linux para controlar el acceso a NFS y Identity and Access Management (IAM) para controlar el acceso a las operaciones de instancias, como crear, editar, ver y borrar instancias. En la siguiente guía, se explica cómo completar cada una de estas tareas.

Configuración de exportación de recurso compartido de archivos

A un archivo compartido de Filestore se le asigna la siguiente configuración predeterminada de /etc/exports:

  • La lista de clientes, que identifica a los clientes a los que se les permite conectarse al recurso compartido, contiene todas las direcciones IP internas de la red de VPC que seleccionaste para la instancia de Filestore. Las direcciones IP internas pueden ser cualquier rango enumerado en los rangos de subredes. Sin embargo, si tienes clientes en rangos de subred distintos deRFC 1918, debes otorgarles acceso de manera explícita a la instancia de Filestore medianteControl de acceso basado en IP.
  • Se usa la opción rw, por lo que el recurso compartido de archivos permite operaciones de lectura y escritura.
  • Se utiliza la opción no_root_squash de asignación de ID del usuario, por lo que se espera que todos los usuarios y grupos, incluido el usuario raíz, sean los mismos tanto en la instancia de Filestore como en el cliente.
  • Todas las demás opciones usan los valores predeterminados de /etc/exports.

Instancias de nivel básico

Las instancias SSD básico y HDD crean un recurso compartido exportado etiquetado como /config/google-prober, que se usa para admitir procesos de sondeo internos que, a su vez, verifican el acceso, la durabilidad o el rendimiento. El recurso compartido se exporta a una lista de clientes a la que solo puede acceder la dirección IP de la instancia, con la misma configuración que se indica en la sección anterior. Solo los verificadores alojados en la instancia o que se originan en ella pueden acceder al recurso compartido, y no se puede acceder a él fuera de la instancia. La instancia exporta el recurso compartido independientemente de si se aplica el control de acceso basado en IP. Los usuarios pueden ver el recurso compartido exportado con el comando showmount -e.

Control de acceso basado en IP

Puedes cambiar esta configuración de exportación si creas reglas de control de acceso con la consola de Google Cloud o si especificas un archivo de configuración JSON durante la creación de la instancia con gcloud CLI. Para obtener más información, consulta Configurar el control de acceso basado en IP.

También puedes agregar nuevas reglas de control de acceso o modificar las existentes después de crear una instancia. Para obtener más detalles, consulta Edita instancias.

Permisos para recursos compartidos de archivo

Cuando creas una instancia de Filestore, el recurso compartido para esa instancia tiene permisos de archivo POSIX predeterminados de rwxr-xr-x. Estos permisos significan que, en una instancia de Filestore, solo los usuarios raíz de los clientes conectados tienen acceso de lectura y escritura al recurso compartido. Los otros usuarios solo tienen acceso de lectura de forma predeterminada. Los usuarios raíz del cliente pueden cambiar los permisos y los propietarios.

Configura el acceso de un recurso compartido de archivo

Cuando activas un recurso compartido, puedes usar las opciones de activación y la configuración de /etc/fstab para determinar si el recurso compartido de archivos puede escribirse y si se pueden ejecutar archivos en él. Después de activar el recurso compartido de archivos, puedes usar comandos estándar de Linux, como chmod y setfacl, para configurar los permisos de los archivos y del recurso compartido de archivos. Solo los niveles básicos admiten setfacl.

Establece permisos coherentes

Te recomendamos que establezcas permisos coherentes para cada usuario en todos los clientes que se conecten a la misma instancia de Filestore para evitar la elevación de privilegios. Si un recurso compartido de archivos se activa en más de un cliente y un usuario tiene privilegios de administrador en un cliente, pero no en los demás, es posible que se produzca la siguiente situación de elevación de privilegios:

  • Un usuario establece el atributo setuid en un archivo ejecutable desde el cliente en el que tiene acceso raíz.
  • Luego, el usuario sube el archivo ejecutable al recurso compartido de archivos.
  • El usuario ejecuta el archivo subido como raíz en cualquier cliente en el que tenga, por lo menos, permiso de lectura.

Esta situación es posible porque el bit setuid permite que el usuario ejecute un archivo con los permisos del propietario del archivo, que en este caso es el usuario raíz.

Permisos superpuestos

Las instancias regionales, zonales y empresariales ahora admiten permisos superpuestos.

Si se definen dos reglas de control de acceso independientes para subredes de direcciones IP superpuestas, la regla definida para la subred más pequeña tiene prioridad.

Por ejemplo, si un archivo de configuración JSON contiene una regla que otorga acceso de lectura y escritura a la subred de direcciones IPv4 10.0.0.0/24 y una regla independiente otorga acceso de solo lectura a la subred de direcciones IPv4 10.0.0.0/28, Filestore reconoce y aplica primero la regla para la subred más pequeña. Luego, la otra regla se aplica a las partes restantes de la subred de direcciones IP definida. En este ejemplo, a un cliente que usa la dirección IPv4 10.0.0.20 se le otorgan permisos de lectura y escritura, mientras que a un cliente que usa 10.0.0.12 se le otorgan permisos de solo lectura:

   {
  "--file-share":
    {
      "capacity": "2048",
      "name": "my_vol",
      "nfs-export-options": [
        {
          "access-mode": "READ_WRITE",
          "ip-ranges": [
            "10.0.0.0/24"
          ],
          "squash-mode": "ROOT_SQUASH",
          "anon_uid": 1003,
          "anon_gid": 1003
        },
         {
          "access-mode": "READ_ONLY",
          "ip-ranges": [
            "10.0.0.0/28"
          ],
          "squash-mode": "NO_ROOT_SQUASH"
        }
      ]
    }
}

Se aplican algunas restricciones:

  • No se admiten permisos superpuestos para subredes IPv4 idénticas y se muestra un error.

  • Los permisos superpuestos no son compatibles con las instancias básicas de SSD ni de HDD.

¿Qué sigue?