Dicen que tarde o temprano, todo lo bueno llega a su fin, y para bien o para mal, la titánica tarea de escribir una serie de artículos dedicados a la construcción de una landing zone corporativa sobre AWS está a punto de concluir.
Así, tras un primer escrito de introducción, seguido de los textos enfocados en el accounting, networking y logging, le llega el turno al Single Sign-On. Sin más dilación, comenzamos.
IAM
Todos aquellos que acumuléis cierta experiencia en AWS, estaréis más que familiarizados con AWS Identity and Access Management, comúnmente conocido como IAM, servicio que permite controlar de forma segura el acceso individual y grupal a los recursos en la nube de Amazon.
Sin entrar en mucho detalle, IAM maneja el concepto de usuarios (tanto personas físicas como service accounts), que pueden pertenecer a uno o varios grupos, a los que a su vez se les asignan uno o más roles, que no hacen mas que aglutinar un conjunto de políticas que conceden permisos sobre recursos de AWS.
Trasladado esto a un ejemplo práctico, el usuario Bob pertenece al grupo Champion Architects, que tiene asignado el rol de Administrador, el cual internamente contiene políticas que le conceden acceso total a sobre todos los recursos de la cuenta.
El problema que presenta esta solución es que no esta diseñada para gestionar de forma centralizada el acceso de los usuarios de una organización a lo largo de una estructura multi-cuenta de AWS.
No hay mas que ver como, si nuestro querido Bob, creado en una cuenta “A” que aglutina la gestión de identidades de toda la organización, quiere hacer login en la cuenta “B”, debería de:
- Crear un rol en la cuenta “B” que contenga las políticas que concedan permisos sobre el conjunto de recursos de AWS requerido.
- Crear un rol en la cuenta de “A” que contenga una política permita asumir el rol de la cuenta “B” previamente creado.
- Asignar el rol de la cuenta A al grupo al que pertenece Bob.
- Bob hace login en la cuenta A.
- Bob hace un switch-role para acceder a la cuenta B.
Las principales desventajas que presenta, aparte de ser un proceso arduo y tedioso, son que la gestión de los usuarios no es realmente centralizada, ya que requiere actuar sobre al menos dos cuentas, y que no es posible reutilizar los roles o permisos entre ellas. En otras palabras, en caso de definir un rol developer en la cuenta “B”, no solo habrá que crearlo sino también mantenerlo en el tiempo en una hipotética cuenta “C”.
Tampoco es que disponga de una integración nativa con identity provider externos como el archiconocido Active Directory de Microsoft, un requisito o necesidad de lo más habitual en todas aquellas organizaciones que quieren iniciar un Journey to Cloud.
Al fin y al cabo, no es plato de buen gusto duplicar los usuarios y grupos de la infraestructura on-premise en la nube, disponer credenciales distintas en cada lugar, o tener que preocuparse de dar de baja a los empleados en ambos sistemas cuando abandonan la compañía.
Por suerte, no está todo perdido, ya que AWS dispone de otro servicio para suplir todas estas carencias.
AWS SSO
Tal y como define la documentación oficial de Amazon, AWS Single Sign-On (AWS SSO) es el servicio donde se crean, o se conectan, las identidades del personal en AWS una vez y se administra el acceso de forma centralizada en toda la organización de AWS.
Su modus operandi es muy similar a IAM, es decir, maneja el concepto de usuarios, que pueden pertenecer a uno o varios grupos, a los que a su vez se les asignan uno o más permission sets (en la lengua común roles), que no hacen mas que aglutinar un conjunto de políticas que conceden permisos sobre recursos de AWS.
La gran diferencia es que estos permission sets se asignan de forma centralizada no sobre los grupos (o usuarios directamente), sino sobre una conjunción de ambos. Volviendo al ejemplo de antes, el usuario Bob sigue perteneciendo al grupo Champion Architects, pero en este caso se le asigna el rol de Administrador sobre una cuenta especifica de la unidad organizativa de Workload.
De un plumazo este servicio solventa todas las problemáticas previamente comentadas, dado que ahora la gestión de los usuarios sí que está centralizada en una única cuenta y es posible reutilizar los permission sets (roles) entre ellas.
Así, si el que a estas alturas ya debería ser nuestro mejor amigo Bob, creado a través de SSO en la cuenta management de AWS Organization, quiere hacer login en la cuenta “B”, tan solo debería:
- Crear o reutilizar en la cuenta de management un permission set que contenga las políticas que concedan permisos sobre el conjunto de recursos de AWS requerido.
- Asignar dicho rol, al grupo al que pertenece Bob, sobre la cuenta B.
- Bob hace login en un portal único y selecciona la cuenta a la que acceder, con el rol asignado.
Como podéis percibir, la experiencia de usuario mejora ostensiblemente, al no tener que llevar a cabo el tedioso switch-role cada vez que uno quiere cambiar de cuenta, tan solo seleccionar a través de un portal el destino deseado (lo que los habéis sufrido sabréis bien a que me refiero). Además, este portal también provee las claves necesarias (Access key ID y Secret access key) para un acceso programático.
Para quien tenga curiosidad, comentar qué, “behind the scenes”, funciona exactamente igual que IAM, con su rol en la cuenta destino y el assume role en la cuenta principal, pero AWS SSO lo encapsula para hacerlo transparente al usuario. De hecho, sí accediéramos a la cuenta “B” empleada en el ejemplo anterior, veríamos dicho rol en la sección correspondiente de IAM.
Si todavía albergarais alguna duda de que es la opción mas adecuada para un entorno multicuenta, comentar que es totalmente gratuito, viene configurado de caja con AWS Control Tower y se integra con AWS Organizations, lo que dice mucho de la importancia que le da AWS. No seria de extrañar que en unos años pasara a ser la opción por defecto de la nube.
Finalmente, destacar AWS SSO ofrece la posibilidad de integrarse con distintos proveedores de identidad externos, entre los que se encuentra el directorio activo (AD) de Microsoft, independientemente de sí está alojado en la infraestructura on-premise o en la nube, solventando las problemáticas previamente destacadas en la sección de IAM.
Todo esto es posible gracias a AWS Directory Service, servicio que permite gestionar la conexión entre ambos sistemas de las siguientes maneras:
- AD Connector: Modalidad que despliega un Directory Gateway que actúa a modo de proxy redirigiéndo las peticiones de login al AD corporativo, sin cachear información alguna.
- Two-way trust relationship: Modalidad que despliega un Active Directory completamente funcional a través de AWS Managed Microsoft AD y establece una relación de confianza bidireccional con el AD corporativo, para poder leer información de usuarios y grupos del dominio, asi como redigirir las peticiones de login.
Las diferencias entre ambos bien merecen un extenso artículo en exclusiva, que tarde o temprano acabara haciendo acto de presencia en esta casa. Si no podéis esperar, advertios de que las frías recomendaciones de la documentación oficial de Amazon no son suficientes para tomar una elección y que lo ideal es que realicéis el correspondiente análisis por vuestro lado.
Conclusiones
En conclusión, a lo largo del articulo se han descrito las dos opciones existentes para la gestión de identidades, dentro de una estructura multi-cuenta de AWS como la que propone la Landing Zone, siendo AWS Single Sign-On (AWS SSO) la opción más recomendada por ser capaz de proporcionar un punto centralizado para la gestión de usuarios y su integración nativa con identity providers externos.
Y ahora sí, tras 6 escritos de lo más variopintos, finaliza la serie de artículos dedicados a la construcción de una landing zone corporativa sobre AWS, basada en las best practises recomendadas por Amazon. Espero que os haya sido de ayuda y suerte en vuestro J2C.
Referencias
Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:
Mikel's TechBlog 