IAM en AWS: el modelo mental que me hizo clic
Guía para estudiantes sobre usuarios, grupos, políticas y roles de IAM, y cómo se conectan entre sí. Escrita para quien encontró IAM confuso.
Soy estudiante de ciencia de datos e ingeniero de datos junior, y cuando abrí la consola de IAM de AWS por primera vez me sentí perdido. Usuarios, grupos, roles, políticas, basadas en identidad, basadas en recurso... parecía que todo estaba conectado con todo, y nada tenía sentido por sí solo.
Si estás en ese mismo punto ahora, te prometo que se aclara. Este artículo es yo compartiendo el modelo mental que por fin me hizo clic.
La analogía del edificio
Piensa en tu cuenta de AWS como un edificio de oficinas. IAM es el sistema de seguridad que controla quién entra, a qué pisos puede subir y qué puede hacer una vez adentro.
Los usuarios de IAM son las personas con carné.
Los grupos de IAM son los departamentos a los que pertenecen esas personas.
Las políticas de IAM son las reglas de acceso impresas en cada carné o asignadas a cada departamento.
Los roles de IAM son pases temporales de visitante que cualquiera, o cualquier servicio, se puede poner cuando necesita un acceso específico.
Vamos uno por uno.
Usuarios de IAM: tu identidad en AWS
Un usuario de IAM es una identidad permanente. Cuando creas uno, estás diciendo "esta persona, o esta aplicación, existe y puede interactuar con mi cuenta de AWS".
Cada usuario puede tener un nombre de usuario y una contraseña, para entrar a la consola de AWS, y claves de acceso, para interactuar con AWS desde la CLI o el SDK.
Lo clave: un usuario por sí solo no puede hacer nada. Hasta que le adjuntas una política, un usuario de IAM recién creado tiene cero permisos. Ese es el principio de menor privilegio en acción: empiezas sin nada y otorgas explícitamente lo que hace falta.
Grupos de IAM: organizar usuarios por función
Imagina que tienes 10 desarrolladores y 5 ingenieros de datos. Podrías adjuntar la misma política a cada uno de esos 15 usuarios, uno por uno, pero eso es un dolor de cabeza de mantener. ¿Y si necesitas cambiar algo?
Para eso sirven los grupos. Un grupo es simplemente una colección de usuarios. Adjuntas las políticas al grupo, y cada usuario del grupo hereda esos permisos.
Un par de cosas que hay que saber: un usuario puede pertenecer a varios grupos, los grupos no se pueden anidar, y los grupos son para organizar humanos, porque los servicios de AWS no pertenecen a grupos.
Ejemplo: creas un grupo llamado DataEngineers y le adjuntas una política que permite acceso a S3, Glue y Athena. Cada usuario que agregues a ese grupo recibe esos permisos automáticamente. ¿Necesitas dar de alta a alguien nuevo? Lo agregas al grupo y listo.
Políticas de IAM: las reglas que definen el acceso
Aquí es donde todo se junta. Una política es un documento JSON que define quién puede hacer qué, sobre qué recursos y bajo qué condiciones.
Esta es la política más simple que vas a ver, y permite absolutamente todo:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Un detalle que me confundió al principio
AWS trae más de 1.000 políticas administradas, ya construidas por ellos. También puedes escribir políticas propias. Cuando estás empezando, usa políticas administradas como AmazonS3ReadOnlyAccess en vez de escribir JSON desde cero. Siempre puedes afinarlo después.
Roles de IAM: acceso temporal para servicios y entre cuentas
Este es el concepto que más me costó entender, así que voy a ser extra claro.
Un rol no es un usuario. Un rol no tiene contraseña ni credenciales permanentes. Un rol es un conjunto de permisos que puede ser asumido temporalmente por quien, o por lo que, los necesite.
¿Por qué importa esto? Tres escenarios que me lo hicieron clic.
Escenario 1, servicios de AWS: tienes una función Lambda que necesita leer de S3. Lambda no es una persona, no puede tener usuario y contraseña. En vez de eso creas un rol con permisos de lectura sobre S3 y se lo asignas a la función. Cuando la función corre, AWS le entrega credenciales temporales a través de ese rol.
Escenario 2, acceso entre cuentas: tu empresa tiene una cuenta de producción y una de desarrollo. Un desarrollador de la cuenta de desarrollo necesita leer logs de producción. En vez de crear un usuario en producción, que es riesgoso, creas un rol en producción que el usuario de desarrollo puede asumir temporalmente.
Escenario 3, usuarios federados: tu empresa usa Active Directory o Google Workspace. En vez de crear usuarios de IAM para cada empleado, estos asumen un rol cuando entran a través de tu proveedor de identidad.
La magia de los roles es que las credenciales son temporales y AWS las rota automáticamente. No hay claves de acceso guardadas en un archivo .env esperando a filtrarse.
Esa es la política AdministratorAccess. En producción nunca se la darías a todo el mundo, pero sirve para ver la estructura: Effect es Allow o Deny, Action son las llamadas a la API que se permiten, Resource son los recursos específicos sobre los que aplican esas acciones, por ejemplo el ARN de un bucket de S3, y Condition, que es opcional, agrega reglas extra como "solo desde esta IP" o "solo si hay MFA activo".
Hay dos tipos principales de políticas. Las basadas en identidad se adjuntan a un usuario, un grupo o un rol, y dicen "esta identidad puede hacer X". Las basadas en recurso se adjuntan a un recurso, como un bucket de S3, y dicen "este recurso permite que la identidad Y interactúe con él".
Cuando existen las dos, AWS las evalúa juntas. Un deny explícito siempre le gana a cualquier allow.
Un detalle que me confundió al principio
AWS trae más de 1.000 políticas administradas, ya construidas por ellos. También puedes escribir políticas propias. Cuando estás empezando, usa políticas administradas como AmazonS3ReadOnlyAccess en vez de escribir JSON desde cero. Siempre puedes afinarlo después.
Roles de IAM: acceso temporal para servicios y entre cuentas
Este es el concepto que más me costó entender, así que voy a ser extra claro.
Un rol no es un usuario. Un rol no tiene contraseña ni credenciales permanentes. Un rol es un conjunto de permisos que puede ser asumido temporalmente por quien, o por lo que, los necesite.
¿Por qué importa esto? Tres escenarios que me lo hicieron clic.
Escenario 1, servicios de AWS: tienes una función Lambda que necesita leer de S3. Lambda no es una persona, no puede tener usuario y contraseña. En vez de eso creas un rol con permisos de lectura sobre S3 y se lo asignas a la función. Cuando la función corre, AWS le entrega credenciales temporales a través de ese rol.
Escenario 2, acceso entre cuentas: tu empresa tiene una cuenta de producción y una de desarrollo. Un desarrollador de la cuenta de desarrollo necesita leer logs de producción. En vez de crear un usuario en producción, que es riesgoso, creas un rol en producción que el usuario de desarrollo puede asumir temporalmente.
Escenario 3, usuarios federados: tu empresa usa Active Directory o Google Workspace. En vez de crear usuarios de IAM para cada empleado, estos asumen un rol cuando entran a través de tu proveedor de identidad.
La magia de los roles es que las credenciales son temporales y AWS las rota automáticamente. No hay claves de acceso guardadas en un archivo .env esperando a filtrarse.
Cómo se conecta todo
Este es el flujo que por fin me ordenó las ideas. Los usuarios son quien eres, tu identidad permanente en AWS. Los grupos organizan usuarios, para que manejes permisos a escala y no de a uno. Las políticas definen qué puedes hacer, son las reglas en JSON adjuntas a usuarios, grupos o roles. Y los roles son en qué te conviertes temporalmente, cuando tú o un servicio necesitan un acceso distinto.
Errores que cometí para que tú no tengas que cometerlos
Dar AdministratorAccess a todo porque "es solo para probar". Siempre es "solo para probar" hasta que deja de serlo. Empieza restrictivo.
Crear usuarios de IAM para aplicaciones en vez de usar roles. Si tu instancia EC2 o tu Lambda necesitan acceso a AWS, usa un rol. Nunca claves escritas en el código.
Olvidar que el deny siempre gana. Si una política dice Allow y otra dice Deny para la misma acción, el resultado es Deny. Sin excepciones.
No activar MFA, sobre todo en la cuenta root. Si no lo has hecho, hazlo ahora mismo.
Qué sigue
Cuando ya estés cómodo con estos cuatro conceptos, la siguiente capa es AWS Organizations y las SCPs, las políticas de control de servicio, para gobernar varias cuentas; IAM Identity Center, antes AWS SSO, para gestión centralizada de accesos; y los Permission Boundaries, como barrera avanzada para el máximo de permisos posibles.
Para cerrar
IAM me pareció abrumador al principio porque todo parecía referirse a todo lo demás. Pero una vez que entendí que en el fondo son cuatro bloques, usuarios, grupos, políticas y roles, y que las políticas son el pegamento que los conecta a todos, empezó a tener sentido.
Si estás estudiando para una certificación, armando tu primer proyecto, o simplemente tratando de entender por qué tu Lambda no puede leer ese bucket de S3, espero que esto te haya servido. Deja un comentario si algo todavía te confunde, lo más probable es que yo haya sufrido con lo mismo.
Esta guía también está en inglés: https://builder.aws.com/content/3JQtlNGo4LZgHZQ4rOi82sI0jUy/aws-iam-basics-the-mental-model-that-finally-made-it-click
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article