IAM Roles en AWS

🔍 ¿Qué es IAM Roles?

Un IAM Role (Rol de IAM) es una identidad dentro de AWS con permisos específicos, similar a un usuario, pero no está asociada a una persona en particular. En vez de tener una contraseña o claves permanentes, los roles entregan credenciales temporales que permiten acceder a recursos de AWS.

👉 ¿La diferencia clave? Los roles están hechos para ser asumidos por quien los necesite, como servicios, usuarios temporales, otras cuentas, o incluso identidades externas.

---

❓¿Qué hace un rol IAM?

• Permite otorgar permisos sin necesidad de crear usuarios individuales.

• Proporciona credenciales temporales seguras.

• Se puede usar entre servicios o entre cuentas.

• Controla el acceso y las acciones sobre recursos específicos de AWS.

👩‍🏫 Analogía para entender IAM Roles:

Imagina que en una empresa hay una sala de servidores. Esa sala solo permite la entrada con una tarjeta de acceso especial.

• A veces entra el personal de mantenimiento, otras veces el de seguridad o un técnico externo.

• Cada vez, en vez de tener una tarjeta fija, se les presta una tarjeta temporal con acceso limitado, solo mientras hacen su tarea.

💡 Esa tarjeta es como un IAM Role: no está asignada a una persona fija, sino que puede ser asumida por cualquiera que cumpla las condiciones, y solo por un tiempo limitado.

🛠️ Tipos de Roles IAM

IAM tiene varios tipos de roles dependiendo de quién lo va a usar y para qué fin. Aquí te explico los 4 principales:

1. 🧰 Rol para Servicio de AWS (Service Role)

👉 Este tipo de rol lo asumen los servicios de AWS para hacer tareas por ti.

✅ ¿Cuándo se usa?

Cuando necesitas que un servicio como EC2, Lambda, ECS, etc., tenga permisos para acceder a otros servicios.

🧠 Ejemplo:

Tienes una función Lambda que guarda archivos en un bucket S3. Lambda por sí sola no tiene permisos. Le asignas un rol IAM con permisos de S3 para que pueda hacerlo.

🪄 Analogía:

Es como darle una tarjeta de acceso a un robot (EC2, Lambda) para que pueda entrar al depósito (S3) y dejar un paquete.

👩‍🔧 ¿Cómo se configura?

• Se define una política de permisos (por ejemplo, acceso de escritura a S3).

• Se configura como "rol de ejecución" al servicio (por ejemplo, al crear la Lambda, se le asigna el rol).

2. 🔗 Rol Vinculado al Servicio (Service-Linked Role)

👉 Es una variante especial del rol anterior. Estos roles son creados automáticamente por AWS para que un servicio funcione correctamente.

✅ ¿Cuándo se usa?

Cuando activas ciertas características de un servicio que necesitan permisos internos, AWS crea el rol por ti y lo vincula al servicio.

🧠 Ejemplo:

Activas la protección automática de instancias con Elastic Load Balancer. AWS crea un rol vinculado para que el ELB pueda verificar el estado de las instancias y reemplazarlas si fallan.

🪄 Analogía:

Es como si el edificio (AWS) detecta que contrataste un sistema de seguridad (servicio) y automáticamente genera una tarjeta con los accesos justos que necesita ese sistema.

👩‍🔧 ¿Cómo se configura?

• AWS lo crea por ti. Tú no tienes que escribir la política.

• Solo puedes verlos y eliminarlos desde la consola o CLI.

• Se nombran con un formato como: AWSServiceRoleForElasticLoadBalancing

3. 🧳 Rol para Cuenta Externa (Cross-Account Role)

👉 Permite a otra cuenta de AWS asumir un rol en tu cuenta, con permisos definidos.

✅ ¿Cuándo se usa?

Cuando necesitas que otra cuenta acceda a tus recursos, por ejemplo:

• Tu equipo tiene múltiples cuentas (dev, staging, prod) y necesitas compartir acceso.

• Estás integrando con un partner externo.

🧠 Ejemplo:

Tu empresa tiene dos cuentas de AWS: una para producción y otra para desarrollo. Desde desarrollo quieres poder leer logs de producción. Se crea un rol en producción que permite a los usuarios de desarrollo asumirlo y leer logs.

🪄 Analogía:

Es como dar una tarjeta de visitante a alguien de otro edificio (otra cuenta), con acceso limitado solo a ciertas áreas.

👩‍🔧 ¿Cómo se configura?

• En la cuenta destino (la que tiene los recursos) se crea un rol con una política de confianza que autoriza a otra cuenta a asumirlo.

• En la cuenta origen, el usuario debe asumir el rol con sts:AssumeRole.

4. 🌐 Rol para Usuarios Federados (Federated Identity Role)

👉 Este rol permite a personas que no tienen un usuario IAM, como usuarios corporativos o apps externas, acceder a AWS de forma temporal.

✅ ¿Cuándo se usa?

Cuando usas proveedores de identidad externos como Google, Facebook, Active Directory, SAML, etc., y quieres evitar crear usuarios IAM manuales.

🧠 Ejemplo:

Tu empresa usa Active Directory corporativo. Quieres que tus empleados accedan a la consola de AWS sin tener que crearles cuentas IAM. Usas federación con SSO (Single Sign-On) y les asignas un rol cuando inician sesión

🪄 Analogía:

Es como si al entrar con tu carnet de la empresa, el sistema detecta quién eres y te da una tarjeta temporal para AWScon permisos según tu rol interno (dev, admin, etc.).

👩‍🔧 ¿Cómo se configura?

• Se usa AWS IAM Identity Center (antes AWS SSO) o un proveedor como Cognito, Google, SAML, etc.

• Al autenticarse, el usuario obtiene credenciales temporales y asume un rol con permisos limitados.

🧩 Resumen de los tipos de Roles

🧠 Conceptos clave relacionados

📍 Escenario real de uso

Supón que tienes una aplicación web en EC2 que necesita subir imágenes a un bucket en S3. En vez de poner claves directamente en el código (lo cual es peligroso), asignas a la instancia EC2 un IAM Role con permisos para acceder solo a ese bucket.

✅ Seguridad, ✅ Buenas prácticas, ✅ Escalable.

---

🪄 Analogía unificada (estilo tarjeta temporal con función específica)

Usaremos la misma analogía para reforzar conceptos:

El edificio corporativo tiene diferentes zonas (como los servicios de AWS: S3, RDS, EC2).
Cuando alguien (usuario, servicio, sistema externo) necesita entrar a una zona, se le presta una tarjeta temporal (IAM Role) que define a qué puertas puede entrar (permisos) y por cuánto tiempo (credenciales temporales).
Algunas tarjetas ya están prediseñadas por el edificio (roles vinculados), otras las define el jefe de seguridad (delegación), y otras se le dan a visitantes externos que vienen con una carta de confianza (federación).

💡 Diferencias clave entre Usuarios IAM vs Roles IAM

🧪 ¿Cuándo usar IAM Roles?

✅ Cuando una instancia de EC2 o Lambda necesita acceder a otro servicio como S3 o DynamoDB.
✅ Cuando una cuenta diferente necesita acceder a tus recursos.
✅ Cuando usas login corporativo o autenticación externa.
✅ Cuando quieres separar identidades de permisos, sin atarlos a personas.

🛠️ Notas técnicas relevantes

• Un rol no tiene contraseña ni claves a largo plazo.

• Puedes auditar el uso de los roles con CloudTrail.

• Los roles pueden tener una duración limitada (hasta 12h según configuración).

• Puedes usar el servicio AWS STS para solicitar credenciales temporales.