Hace años, cuando los servidores Unix locales con grandes sistemas de archivos eran algo habitual, las empresas creaban extensas reglas de gestión de carpetas y estrategias para administrar los derechos de acceso a diferentes carpetas para diferentes personas.
Normalmente, la plataforma de una organización sirve a diferentes grupos de usuarios con intereses, restricciones de nivel de confidencialidad o definiciones de contenido completamente distintos. En el caso de organizaciones globales, esto podría significar incluso separar el contenido en función de la ubicación, así que básicamente, entre los usuarios pertenecientes a diferentes países.
Otros ejemplos típicos podrían ser
- separación de datos entre entornos de desarrollo, prueba y producción
- contenido de ventas no accesible a un público amplio
- contenido legislativo específico de un país que no se puede ver o al que no se puede acceder desde otra región
- contenidos relacionados con proyectos en los que los «datos de liderazgo» sólo deben proporcionarse a un grupo limitado de personas, etc.
Existe una lista potencialmente interminable de ejemplos de este tipo. La cuestión es que siempre existe algún tipo de necesidad de orquestar los derechos de acceso a los archivos y datos entre todos los usuarios a los que la plataforma proporciona acceso.
En el caso de las soluciones locales, se trataba de una tarea rutinaria. El administrador del sistema de archivos simplemente establecía algunas reglas, utilizaba una herramienta de su elección y, a continuación, las personas se asignaban a grupos de usuarios, y los grupos de usuarios se asignaban a una lista de carpetas o puntos de montaje a los que deberían poder acceder. Por el camino, el nivel de acceso se definía como acceso de sólo lectura o de lectura y escritura.
Ahora, si nos fijamos en las plataformas en la nube de AWS, es obvio esperar que las personas tengan requisitos similares para las restricciones de acceso a los contenidos. La solución a este problema debe ser, sin embargo ahora, diferente. Los archivos ya no resisten en servidores Unix sino en la nube (y potencialmente accesibles no sólo a toda la organización sino incluso a todo el mundo), y el contenido no se almacena en carpetas sino en buckets S3.
A continuación se describe una alternativa para abordar este problema. Se basa en la experiencia real que tuve mientras diseñaba este tipo de soluciones para un proyecto concreto.
Enfoque simple pero enormemente manual
Una forma de resolver este problema sin ningún tipo de automatización es relativamente directa y sencilla:
- Cree un nuevo bucket para cada grupo distinto de personas.
- Asigne derechos de acceso al cubo para que sólo este grupo específico pueda acceder al cubo S3.
Esto es ciertamente posible si el requisito es ir con una resolución muy simple y rápida. Sin embargo, hay que tener en cuenta algunos límites.
Por defecto, sólo se pueden crear hasta 100 cubos de S3 bajo una cuenta de AWS. Este límite puede ampliarse a 1000 enviando un aumento del límite de servicio al ticket de AWS. Si esos límites no son algo que preocupe a su caso de implementación particular, entonces puede dejar que cada uno de sus usuarios de dominio distintos opere en un cubo de S3 independiente y dar por zanjado el asunto.
Los problemas pueden surgir si hay algunos grupos de personas con responsabilidades interfuncionales o simplemente algunas personas que necesitan acceder al contenido de más dominios al mismo tiempo. Por ejemplo:
- Analistas de datos que evalúan el contenido de los datos de varias áreas, regiones, etc. diferentes.
- El equipo de pruebas compartiendo servicios al servicio de diferentes equipos de desarrollo.
- Los usuarios de informes que necesitan elaborar análisis de cuadros de mando sobre distintos países de una misma región.
Como puede imaginar, esta lista puede volver a crecer tanto como pueda imaginar, y las necesidades de las organizaciones pueden generar todo tipo de casos de uso.
Cuanto más compleja sea esta lista, más compleja será la orquestación de los derechos de acceso necesaria para conceder a todos esos grupos diferentes derechos de acceso a los distintos buckets de S3 de la organización. Se necesitarán herramientas adicionales, y tal vez incluso un recurso dedicado (administrador) tendrá que mantener las listas de derechos de acceso y actualizarlas cada vez que se solicite algún cambio (que será muy a menudo, sobre todo si la organización es grande).
Entonces, ¿cómo conseguir lo mismo de una forma más organizada y automatizada?
Introducir etiquetas para los buckets
Si el enfoque de cubos por dominio no funciona, cualquier otra solución acabará con cubos compartidos por más grupos de usuarios. En estos casos, es necesario construir toda la lógica de asignación de derechos de acceso en algún área que sea fácil de cambiar o actualizar dinámicamente.
Una de las formas de conseguirlo es utilizando etiquetas en los buckets S3. Se recomienda utilizar las etiquetas en cualquier caso (aunque sólo sea para facilitar la categorización de la facturación). Sin embargo, la etiqueta puede cambiarse en cualquier momento en el futuro para cualquier cubo.
Si toda la lógica se construye basándose en las etiquetas del cubo y el resto detrás es configuración dependiente de los valores de la etiqueta, la propiedad dinámica está asegurada ya que se puede redefinir el propósito del cubo simplemente actualizando los valores de la etiqueta.
¿Qué tipo de etiquetas utilizar para que esto funcione?
Esto depende de su caso de uso concreto. Por ejemplo:
- Puede ser necesario separar cubos por tipo de entorno. Entonces, en ese caso, uno de los nombres de etiqueta será algo así como «ENV» y con valores posibles «DEV», «TEST», «PROD», etc.
- Tal vez quiera separar el equipo en función del país. En ese caso, otra etiqueta será «COUNTRY» y el valor algún nombre de país.
- O puede que quiera separar a los usuarios en función del departamento funcional al que pertenezcan, como analistas de negocio, usuarios del almacén de datos, científicos de datos, etc. Entonces creará una etiqueta con el nombre «USER_TYPE» y el valor correspondiente.
- Otra opción podría ser que desee definir explícitamente una estructura de carpetas fija para grupos de usuarios específicos que deban utilizar (para que no creen su propio desorden de carpetas y se pierdan en él con el tiempo). Puede hacerlo de nuevo con las etiquetas, en las que puede especificar varios directorios de trabajo como: «datos/importación», «datos/procesado», «datos/error», etc.
Lo ideal es definir las etiquetas de forma que puedan combinarse lógicamente y hacer que formen toda una estructura de carpetas en el cubo.
Por ejemplo, puede combinar las siguientes etiquetas de los ejemplos anteriores para construir una estructura de carpetas dedicada a distintos tipos de usuarios de varios países con carpetas de importación predefinidas que se espera que utilicen:
- /
/ / / .
Con sólo cambiar el valor de
Esto permitirá utilizar el mismo bucket para muchos usuarios diferentes. Los cubos no admiten carpetas explícitamente, pero sí «etiquetas». Al final, esas etiquetas funcionan como subcarpetas, porque los usuarios tienen que pasar por una serie de etiquetas para llegar a sus datos (igual que harían con las subcarpetas).
Cree políticas dinámicas y asigne etiquetas a los cubos en su interior
Una vez definidas las etiquetas de alguna forma utilizable, el siguiente paso es crear políticas de cubos S3 que utilicen las etiquetas.
Si las políticas utilizan los nombres de las etiquetas, estará creando algo llamado «políticas dinámicas». Esto significa básicamente que su política se comportará de manera diferente para los cubos con diferentes valores de etiqueta a los que la política se refiere en forma o marcadores de posición.
Este paso implica obviamente cierta codificación personalizada de las políticas dinámicas, pero puede simplificarlo utilizando la herramienta de edición de políticas de Amazon AWS, que le guiará a lo largo del proceso.
En la propia política, querrá codificar los derechos de acceso concretos que se aplicarán al bucket y el nivel de acceso de dichos derechos (lectura, escritura). La lógica leerá las etiquetas de los cubos y construirá la estructura de carpetas del cubo (creando etiquetas basadas en las etiquetas). En función de los valores concretos de las etiquetas se crearán las subcarpetas y se asignarán los derechos de acceso necesarios a lo largo de la línea.
Lo bueno de una política dinámica de este tipo es que puede crear una sola política dinámica y luego asignar la misma política dinámica a muchos cubos. Esta política se comportará de forma diferente para los cubos con distintos valores de etiqueta, pero siempre estará en consonancia con sus expectativas para un cubo con dichos valores de etiqueta.
Es una forma realmente eficaz de gestionar las asignaciones de derechos de acceso de forma organizada y centralizada para un gran número de cubos, donde se espera que cada cubo siga unas estructuras de plantilla acordadas de antemano y que utilizarán sus usuarios en toda la organización.
Automatizar la incorporación de nuevas entidades
Tras definir las políticas dinámicas y asignarlas a los buckets existentes, los usuarios pueden empezar a utilizar los mismos buckets sin el riesgo de que los usuarios de distintos grupos no accedan a contenidos (almacenados en el mismo bucket) situados bajo una estructura de carpetas a la que no tienen acceso.
Además, para algunos grupos de usuarios con un acceso más amplio, será fácil acceder a los datos porque estarán todos almacenados en el mismo bucket.
El último paso es hacer que la incorporación de nuevos usuarios, nuevos buckets e incluso nuevas etiquetas sea lo más sencilla posible. Esto lleva a otra codificación personalizada, que, sin embargo, no tiene por qué ser excesivamente compleja, suponiendo que su proceso de onboarding tenga algunas reglas muy claras que puedan encapsularse con una lógica de algoritmo simple y directa (al menos puede demostrar de esta forma que su proceso tiene cierta lógica y que no está hecho de forma excesivamente caótica).
Esto puede ser tan sencillo como crear un script ejecutable mediante un comando CLI de AWS con los parámetros necesarios para incorporar con éxito una nueva entidad a la plataforma. Incluso puede ser una serie de scripts CLI, ejecutables en algún orden específico, como por ejemplo
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, , ) - etc.
Usted entiende el punto. 😃
Un Pro Tip 👨💻
Hay un Pro Tip si lo desea, que se puede aplicar fácilmente sobre lo anterior.
Las políticas dinámicas pueden aprovecharse no sólo para asignar derechos de acceso a las ubicaciones de las carpetas, ¡sino también para asignar automáticamente derechos de servicio a los cubos y grupos de usuarios!
Todo lo que habría que hacer es ampliar la lista de etiquetas de los cubos y, a continuación, añadir derechos de acceso de políticas dinámicas para utilizar servicios específicos para grupos concretos de usuarios.
Por ejemplo, podría haber algún grupo de usuarios que también necesitara acceder al servidor del cluster de bases de datos específico. Sin duda, esto puede lograrse mediante políticas dinámicas que aprovechen las tareas de los cubos, más aún si los accesos a los servicios se rigen por un enfoque basado en roles. Basta con añadir al código de la política dinámica una parte que procese las etiquetas relativas a la especificación del clúster de base de datos y asigne directamente los privilegios de acceso de la política a ese clúster de base de datos y grupo de usuarios concretos.
De este modo, la incorporación de un nuevo grupo de usuarios será ejecutable sólo mediante esta única política dinámica. Además, al ser dinámica, la misma política puede reutilizarse para el onboarding de muchos grupos de usuarios diferentes (se espera que sigan la misma plantilla pero no necesariamente los mismos servicios).
También puede echar un vistazo a estos comandos de AWS S3 para gestionar buckets y datos.