Documentación de Oracle Cloud Infrastructure

Uso de la autenticación Kerberos

El servicio File Storage ofrece autenticación Kerberos para proporcionar una opción de autenticación compleja.

La seguridad Unix de la versión 3 de NFS, que confía en que el cliente NFS tenga la verdad sobre la identidad de un usuario, solo proporciona la seguridad básica. La identidad del usuario en cada llamada NFS la define el emisor de la llamada y la identidad no es verificada por un tercero de confianza.

Kerberos para NFSv3 ofrece una autenticación compleja tanto para hosts como para usuarios. También puede ofrecer pruebas de la integridad de los datos, garantizar que estos no se alteren y proteger la privacidad de los datos. La integridad de los datos y la privacidad de los datos no son posibles con la seguridad NFS v.3 UNIX sin instalar software de cliente especializado o abrir más puertos TCP.

  • Los usuarios y servicios de una red con Kerberos activado se denominan Principals. Un principal de Kerberos tiene el formato primary/instance@realm. Consulte la documentación principal de MIT Kerberos para obtener más información.
  • El Centro de distribución de claves (KDC) autentica los principales y emite tickets. El KDC mantiene una lista de principales y sus contraseñas.
  • Un dominio consta de todos los principales admitidos por un KDC.

El servicio File Storage admite la autenticación de Kerberos mediante RPCSEC_GSS (RFC2203) con las siguientes opciones de seguridad:

  • Utilice el modo KRB5 para la autenticación mediante NFS
  • Modo de uso KRB5I para autenticación a través de NFS e integridad de datos (modificación no autorizada de datos en tránsito)
  • Utilice el modo KRB5P para la autenticación mediante NFS, la integridad de los datos y la privacidad de los datos (cifrado en tránsito)

Funciones

El soporte del servicio File Storage de Kerberos incluye las siguientes funciones.

cifrado en tránsito

Puede utilizar el modo Kerberos KRB5P, que ofrece privacidad de datos, como alternativa al uso del cifrado TLS v.1.2 (seguridad de capa de transporte). El cifrado TLS v.1.2 requiere la instalación de un paquete denominado oci-fss-utils o el uso de stunnel, según el sistema operativo. El número de conexiones NFS/TLS cifradas para un destino de montaje es limitado, pero el uso de Kerberos con la opción KRB5P permite utilizar el cifrado en tránsito a una escala que no es posible con NFS a través de TLS.

Kerberos y seguridad por IP

La seguridad por IP, definida mediante opciones de exportación NFS, es razonablemente segura si las direcciones IP están en OCI y los hosts son de confianza. Kerberos para NFSv3 puede proporcionar un mayor nivel de seguridad para entornos mixtos o entornos con hosts que no son de confianza.

Puede configurar un bloque CIDR para que necesite Kerberos y otro para la autenticación AUTH_SYS de NFS en la misma exportación. Cualquier cliente que se monte desde la red de confianza no necesitaría montar con Kerberos, pero los clientes que se monten desde la red no de confianza tendrían que usar Kerberos.

Consultas de LDAP y acceso anónimo

Cuando los usuarios tienen una identidad en el KDC, pero no hay información adicional en el servidor LDAP o LDAP no está activado, la operación NFS puede fallar o continuar. El comportamiento en estos casos depende de si activa o no LDAP para el destino de montaje y el acceso anónimo para la exportación.

El acceso anónimo está desactivado por defecto. Cualquier solicitud de NFS asociada con un usuario que no se encuentra falla.

Si el acceso anónimo está activado, las solicitudes asociadas con un usuario que no se encuentra en el servidor LDAP continúan con el UID de Squash y el GID de Squash definidos en las opciones de la exportación. Es posible que desee permitir el acceso anónimo si el proceso de montaje utiliza un principal de Kerberos del sistema que no existe en el servidor LDAP y los derechos squashed permiten que las pocas operaciones de sólo lectura utilizadas por el cliente NFS monten el sistema de archivos.

Escenarios de solicitud NFS para exportaciones activadas para Kerberos
¿ LDAP activado en destino de montaje? Respuesta LDAP ¿Acceso anónimo activado? ¿Exportar squash activado? Solicitud NFS
Todos Todos Todos Sí (todos)

Continúa con Squash UID y Squash GID definidos en las opciones de exportación. No hay lista de grupos secundarios.
Todos Todos Todos Sí (raíz)

Continúa con Squash UID y Squash GID definidos en las opciones de exportación solo después de una respuesta de LDAP correcta donde el nombre de usuario se asigna al UID 0. No hay lista de grupos secundarios.

Si la respuesta de LDAP devuelve un UID que no es 0, continúa con la lista de UID, GID y grupo devueltos.
Si Coincidencia de USERNAME Todos No Utiliza UID, GID y lista de grupos secundarios recuperados del servidor LDAP.
Si No hay coincidencia de USERNAME Si No Continúa con Squash UID y Squash GID definidos en las opciones de exportación. No hay lista de grupos secundarios.
Si No hay coincidencia de USERNAME No No Error con permisos.
Si Error de LDAP que no coincide con ningún usuario Todos No Error con permisos.
No No se aplica Si No

Continúa con Squash UID y Squash GID definidos en las opciones de exportación.
No No se aplica No No Error con permisos.
Nota

Las exportaciones activadas para Kerberos siempre utilizan Use LDAP for Group List cuando Enable LDAP está activado en el destino de montaje.

Para obtener más información, consulte Opciones de exportación NFS.

Requisitos previos

File Storage requiere varios requisitos para utilizar Kerberos para la autenticación.

Entre los requisitos para utilizar la autenticación de Kerberos por usuario se incluyen:

  • Infraestructura LDAP gestionada por el cliente para asignar principales de Kerberos a identidades UNIX. Para obtener más información, consulte LDAP for Authorization Requirements.
  • Infraestructura de Kerberos gestionada por el cliente, con un KDC como MIT o Microsoft Active Directory.
  • Un servidor DNS que puede resolver el nombre de destino de montaje y la dirección IP. Se necesitan las capacidades de consulta directa e inversa.
En esta imagen se muestra la infraestructura gestionada por el cliente y gestionada por OCI necesaria para la autenticación de Kerberos.
  1. Comunicación con un servidor KDC gestionado por el cliente a través del puerto TCP/UDP 88.
  2. Comunicación segura con un destino de montaje activado para Kerberos mediante el puerto NFS 2048/2049/2050 (con cifrado opcional).
  3. Comunicación con el servicio DNS a través del puerto TCP/UDP 53.
  4. Comunicación con el servicio LDAP gestionado por el cliente mediante el puerto TCP configurado en el conector saliente. El valor por defecto es el puerto TCP 636.
  5. Datos cifrados estáticos en File Storage.

Infraestructura LDAP

File Storage utiliza UID y GID para autorizar el acceso a archivos. File Storage utiliza LDAP para asignar principales de Kerberos a UID y GIDS. Para conocer los requisitos detallados de la infraestructura LDAP, consulte Prerequisites for using LDAP for Authorization.

Si File Storage no puede buscar información de autorización de LDAP, es probable que los accesos a NFS para el principal de Kerberos fallen. La autenticación de Kerberos puede utilizarse sin LDAP, pero todos los principales de Kerberos autenticados se tratarán como anónimos. Para obtener más información, consulte LDAP Lookups and Anonymous Access.

Tabla de claves Kerberos

El separador de claves de Kerberos almacenado en OCI Vault debe ser una matriz de cadenas Base64-encoded de la siguiente estructura: 

<principal, key version number, cipher type, symmetric key>

Cada entrada del archivo keytab puede tener solo un principal y ese principal debe incluir el nombre de dominio completo (FQDN) del destino de montaje como su instancia. Un principal puede tener varias entradas con diferentes tipos de cifrado o cifrados.

Por ejemplo, si nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COM es el principal en la tabla de claves, FSS_EXAMPLE.COM es el dominio, fss_test.com es la instancia y nfs es la principal. El FQDN del destino de montaje de este ejemplo debe ser krb_mt1.fss_test.com. Si utiliza un servidor DNS gestionado por el cliente, utilizará este FQDN en comandos de montaje.

Nota

Al utilizar el solucionador de Internet y VCN por defecto, el servicio File Storage crea un FQDN al combinar el nombre de host del destino de montaje con el FQDN de la subred en la que se encuentra el destino de montaje. Después de la creación, el nombre de host se puede cambiar en la página de detalles del destino de montaje. Consulte Gestión de destinos de montaje para obtener más información.

File Storage soporta el siguiente juego de cifrados:

  • aes128-cts-hmac-sha256-128
  • aes256-cts-hmac-sha384-192
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
Nota

OCI File Storage soporta un tamaño máximo de tabla de claves de Kerberos de 1024 bytes.
Importante

Valide la tabla de claves de Kerberos antes de activar Kerberos para evitar una interrupción de disponibilidad causada por una tabla de claves no válida. Puede validar la tabla de claves al configurar o revisar la configuración de Kerberos de un destino de montaje.

Al validar el separador de claves de Kerberos mediante la consola, la CLI o la API, el servicio File Storage comprueba lo siguiente:

  • Si el tamaño del archivo keytab es superior a 1024 bytes
  • El número de versión de la tabla de claves no es 1281 ni 1282
  • Si la tabla de claves contiene entradas nulas
  • Si el archivo keytab tiene entradas con nombres de principales diferentes
  • Si la tabla de claves tiene más de 12 entradas, que es el máximo
  • Si el tipo de codificación de tabla de claves no es uno de los siguientes:
    • ETYPE_AES128_CTS_HMAC_SHA1_96
    • ETYPE_AES256_CTS_HMAC_SHA1_96
    • ETYPE_AES128_CTS_HMAC_SHA256_128
    • ETYPE_AES256_CTS_HMAC_SHA384_192
Nota

Un separador de claves extraído del KDC en formato binario se debe convertir a Base64 y, a continuación, se debe utilizar para crear un secreto en el almacén de OCI. Asegúrese de seleccionar Base64 como el formato del secreto al pegarlo en el separador de claves convertido.

File Storage soporta la rotación de keytab mediante un keytab de copia de seguridad. Consulte Rotating Keys para obtener más información.

Consideraciones y limitaciones

Al utilizar Kerberos para la autenticación de File Storage, tenga en cuenta la siguiente información y los límites.

  • Para la autenticación Kerberos por usuario, File Storage requiere una infraestructura de protocolo de acceso a directorios ligero (LDAP) gestionada por el cliente, incluido un servidor LDAP que admite un esquema POSIX RFC2307.
  • File Storage admite un tamaño máximo de tabla de claves de Kerberos de 1024 bytes.

  • File Storage soporta el siguiente juego de cifrados:

    • aes128-cts-hmac-sha256-128
    • aes256-cts-hmac-sha384-192
    • aes128-cts-hmac-sha1-96
    • aes256-cts-hmac-sha1-96
  • No se recomienda montar sistemas de archivos con las opciones rsize o wsize. Si proporciona valores para estas opciones, File Storage puede reducirlos a 256 KB al utilizar KRB5I o KRB5P.
  • El rendimiento de File Storage al utilizar el modo de autenticación Kerberos KRB5 es aproximadamente equivalente al uso de la autenticación AUTH_SYS. El rendimiento disminuye significativamente al utilizar KRB5P y disminuye ligeramente al utilizar KRB5I. El rendimiento puede variar según la configuración del cliente y el sistema de archivos.

Supervisión y alarmas

Al utilizar la autenticación Kerberos con autorización LDAP, es importante detectar un problema rápidamente. Si la infraestructura de Kerberos o LDAP no funciona correctamente, los clientes NFS podrían perder el acceso a los sistemas de archivos de File Storage que están disponibles mediante sus exportaciones. Para detectar estos problemas, se recomienda configurar alarmas en las métricas del destino de montaje. Las alarmas pueden avisarle de problemas de infraestructura en cuestión de minutos.

Las alarmas creadas a partir de errores de Kerberos, errores de conexión LDAP y errores de solicitud LDAP detectan problemas de conectividad entre destinos de montaje, conectores salientes e infraestructura LDAP gestionada por el cliente.

La siguiente consulta de ejemplo se puede utilizar para crear una alarma para errores de Kerberos:

KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1

La siguiente consulta de ejemplo se puede utilizar para crear una alarma para la conectividad LDAP:

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Para obtener más información sobre la supervisión de métricas y el uso de alarmas, consulte Visión general de Monitoring. Para obtener más información sobre las notificaciones de alarmas, consulte Visión general de Notifications.

Política de IAM necesaria

File Storage necesita acceder a la contraseña del servidor LDAP y montar los secretos del archivo keytab Vault del destino de Kerberos para la configuración de Kerberos. Tanto el usuario que configura el destino de montaje como el propio destino de montaje necesitan acceso de lectura.

Política para gestionar secretos de almacén

Otorgue al usuario o grupo que crea los permisos del secreto de almacén. Para obtener más información, consulte Gestión de secretos de Vault.

Política para activar la configuración de destino de montaje

Otorgue al usuario o grupo que configure Kerberos y LDAP en permisos de destino de montaje mediante una política como la siguiente:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <Keytab_Secret_ID>, target.secret.id = <LDAP_Password_Secret_ID> }

Esto permite al usuario emitir comandos de File Storage que leen los secretos del almacén y que muestren partes del secreto para su validación. File Storage presenta el principal, el número de versión de clave y los tipos de cifrado al usuario que configura el destino de montaje para su validación.

Política para permitir que un destino de montaje recupere secretos

El servicio File Storage requiere la capacidad de leer los secretos. File Storage utiliza principales de recursos para otorgar a un juego específico de destinos de montaje acceso al secreto de almacén. Se trata de un proceso de dos pasos, en primer lugar, los destinos de montaje que necesitan acceso se deben colocar en un grupo dinámico y, a continuación, se otorga acceso al grupo dinámico para leer los secretos.

  1. Cree un grupo dinámico para los destinos de montaje con una política como la siguiente:

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Nota

    Si tiene más de una regla en el grupo dinámico, asegúrese de utilizar la opción Match any rules defined below.

  2. Cree una política de IAM que proporcione al grupo dinámico de destinos de montaje acceso de lectura a los secretos de almacén:

    allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>