Azure Data Lake Storage (ADLS) Gen2 es un servicio de almacenamiento de datos altamente escalable y seguro. Es una solución fundamental para nuestra infraestructura de Analisis de Datos en Azure. ADSL Gen2 implementa un control de acceso basada tanto en Azure RBAC como en POSIX-like Access Control Lists (ACLs).

¿Que son las ACLs?

Las Listas de Control de Acceso, como su nombre lo indica, representan reglas para el manejo del acceso a los directorios o Blob de un DataLake. Nos permiten definir los permisos de acceso a los blobs. Por ejemplo, podrías tener una ACL para un directorio que especifica que un usuario tiene permisos de lectura, un grupo de usuarios tiene permisos de escritura y una aplicación tiene permisos de ejecución. El uso de ACLs permite un control de acceso granular a los datos almacenados.

Entry, Entitys y Security principals

En ADLS, los permisos pueden ser asignados a ‘Security Principals’, que son objetos que representan a un usuario, grupo, ‘service principal’, o una ‘managed identity’ en Azure RBAC. En el contexto de la administración de ACLs, estos ‘security principals’ son denominados como ‘entidades‘, refiriéndose a cualquier objeto que pueda ser asignado con permisos. La asignación de un nivel de acceso específico a una entidad en una ACL se conoce como ‘entry‘.”

Tipos de ACL

Existen 2 tipos:

• Access ACLs: indican el acceso a un objeto.
• Default ACLs: son templates asociados con un directorio y determinan el acceso de los directorios subsiguientes que se encuentren por debajo de su nivel. Quedan asociados a todos los directorios que sean creados. No son aplicables a nivel de archivo.

Niveles de Permisos

Los permisos están basados en el sistema de permisos POSIX (Portable Operating System Interface). Hay tres tipos básicos de permisos:

1. Read (r): En un archivo, el permiso de lectura permite ver el contenido del archivo. En un directorio, permite ver qué archivos y subdirectorios contiene, pero no necesariamente ver el contenido de esos archivos o subdirectorios.
2. Write (w): En un archivo, el permiso de escritura permite modificar el contenido del archivo. En un directorio, permite añadir, modificar o eliminar archivos y subdirectorios, pero no otorga permisos de lectura o ejecución.
3. Execute (x): Este permiso permite a una entidad ejecutar un archivo o acceder a los archivos de un directorio. En un archivo, el permiso de ejecución permite ejecutar el archivo como un programa. En un directorio, permite acceder a los archivos y subdirectorios, pero no otorga permisos de lectura o escritura.

Estos permisos pueden ser asignados a tres tipos diferentes de entidades:

• Un “Super-User” tiene los derechos más amplios, incluidos los permisos RWX para todos los archivos y carpetas, y puede cambiar los permisos, el usuario propietario y el grupo propietario de cualquier archivo o carpeta.
• El “Owner User” es quien creó el ítem y tiene derechos para cambiar los permisos y el grupo propietario de un archivo que posee, siempre que el usuario propietario también sea miembro del grupo objetivo.
• El “Group User” se comporta similar a los permisos asignados para otros usuarios o grupos y puede ser cambiado por cualquier super-usuario o por el usuario propietario si también es miembro del grupo objetivo.}
• El “Mask” entry se usa para especificar los permisos máximos que se pueden asignar a un usuario o grupo. Es un conjunto de permisos que actúa como un filtro, controlando qué permisos están permitidos y cuáles son denegados para los usuarios y grupos especificados en la ACL.

Las identidades se evalúan en el siguiente orden:

1. Super-User,
2. User Owner,
3. Entitys (user o group),
4. Group Owner,
5. Todos los demás usuarios.

Si una identidad tiene múltiples roles, se aplica el nivel de permiso asociado con la primera identidad que se evalúa.

En la lista podemos ver estos permisos por defecto y solo 1 entidad (grupo) con permisos full.

Herencia de Permisos

En ADLS Gen2, los permisos se deben establecer explícitamente para cada archivo y directorio. Aunque podemos definir permisos en el nivel de directorio, estos no se heredarán automáticamente a los subdirectorios y archivos dentro de ese directorio. Por ejemplo, si das permisos de lectura a un grupo en un directorio específico, ese grupo no tendrá automáticamente permisos de lectura para todos los archivos y subdirectorios dentro de ese directorio. Tendrías que otorgar explícitamente esos permisos para cada subdirectorio y archivo.

Para que estos permisos se hereden a los subdirectorios debemos propagarlos. ADLS Gen2 ofrece la opción de establecer permisos de forma recursiva. Esto significa que podemos enuna sola operación aplicar permisos a un directorio y todos sus subdirectorios y archivos. Si un archivo o directorio ya tiene un permiso establecido, aplicar permisos de forma recursiva no cambiará los permisos existentes.

Limites de ACL Entitys

Las ACLs pueden tener un máximo de 32 entitys. Del total 28 son ACL entitys.

Mejores Practicas: utilizar grupos de seguridad

Una de las recomendaciones mas importantes es la utiilzación de grupos de seguridad en lugar de usuarios. Es MUY IMPORTANTE resistirse a la utilización de la asignación de permisos a usuarios directamente. Esto nos dará 2 ventajas:

• Podremos otorgar permisos sin la necesidad de re-aplicar de manera recursiva las ACLs en un directorio completo.
• Evitamos llenar nuestras ACLs y alcanzar el maximo de Entrys.

¿Que pasa si llenamos la ACL de un root directory?

Si llegamos al límite maximo de 32 entrys. No podremos asignar mas permisos en este directorio y en todos sus subdirectorios en caso de que la ACL sea propagada (que suele ser lo mas normal). Para esto podemos utilizar el siguiente repositorio de GitHub:

https://github.com/mdiloreto/AzureDataLake_ACL-User_Entity_to_AADGroup-Scripts

Aquí presentamos una colección de scripts diseñados para gestionar, de manera recursiva, nuestras ACLs usando PowerShell. En particular, el script “02-ReplaceRecursivo_ACLentitys-with-ADSecGroup-v2.ps1” está diseñado para reemplazar todas nuestras entidades de ACL de tipo ‘User’ con un cierto nivel de permisos, eliminándolos de la ACL, añadiéndolos a un grupo de seguridad de Azure AD (AAD) y luego asignando los mismos permisos a ese grupo de AD en la ACL.

Tambien diseñe un script de Rollback “03-RollbackRecursivo-Grant-ACL-from-csv.ps1” que nos permitirá, luego de exportar una ACL a CSV, poder re-asignar los permisos “como estaban” a otro ACL de manera recursiva.