Qué es realmente un rol de IAM

Un IAM role es una identidad que puede asumir para recibir un conjunto de permisos, pero, a diferencia de un usuario, no tiene credenciales permanentes. En su lugar, cuando una entidad asume un rol, AWS emite temporary security credentials que caducan después de un periodo determinado. Los roles son la forma segura y moderna de conceder acceso en AWS y aparecen a lo largo del examen SCS-C02.

Cada rol tiene dos partes de política:

• Una trust policy (también llamada política de asunción de roles) que indica quién puede asumir el rol.
• Una o varias permission policies que indican qué puede hacer el rol una vez asumido.

Esta separación es la base de la delegación segura que permiten los roles: usted decide quién puede tomar prestada la identidad y, por separado, qué puede hacer esa identidad.

Cuando se asume un rol, el Security Token Service (STS) emite un conjunto de credenciales que contiene un ID de clave de acceso, una clave secreta y un session token, todos válidos durante un periodo limitado (de 15 minutos a 12 horas). Como caducan automáticamente, las credenciales temporales filtradas dejan de ser útiles rápidamente, lo que reduce considerablemente el riesgo frente a las claves de acceso de larga duración.

La política de confianza enumera los principals que pueden asumir el rol. Pueden ser:

• Un AWS service (como EC2 o Lambda) para proporcionar una identidad a una carga de trabajo.
• Un IAM user or role de la misma cuenta o de otra cuenta para el acceso entre cuentas.
• Una federated identity de un proveedor SAML u OIDC.

Si un principal no aparece en la política de confianza, nunca podrá asumir el rol, independientemente de lo que permitan las políticas de permisos.

El uso más habitual consiste en permitir que un servicio de AWS actúe en su nombre. Por ejemplo, una instancia de EC2 con un rol asociado puede llamar a S3 sin claves incorporadas; AWS rota las credenciales automáticamente en segundo plano. El examen espera que reconozca que los service roles eliminan los secretos estáticos de sus aplicaciones.

A continuación se muestra un fragmento de una política de confianza que permite al servicio EC2 asumir un rol. Principal identifica quién puede asumirlo, y la acción siempre es sts:AssumeRole.

Los roles son especialmente útiles para el cross-account access. La cuenta A crea un rol que confía en la cuenta B; un principal de B lo asume y recibe credenciales temporales para actuar en A. No se comparten claves, el acceso queda limitado por la política de permisos y cualquiera de las partes puede revocar la confianza en cualquier momento. Esta es la alternativa recomendada a distribuir claves de larga duración entre cuentas.

Las identidades externas, como los usuarios corporativos autenticados mediante SAML o los usuarios de una aplicación mediante la federación de identidades web, también asumen roles. El proveedor de identidades verifica al usuario y, a continuación, AWS emite credenciales temporales asociadas a un rol. Esto significa que las personas no necesitan usuarios de IAM, sino únicamente una identidad verificada que se asigna a un rol.

La mayor ventaja de seguridad de los roles es que no hay credenciales permanentes que robar, rotar o confirmar accidentalmente en un repositorio de código. Los permisos existen únicamente durante una sesión temporal. Esto se ajusta al principio de mínimo privilegio a lo largo del tiempo: el acceso se concede justo cuando se necesita y caduca por sí solo.

Un aspecto sutil: tener permiso para asumir un rol le concede únicamente los permisos del rol, no la combinación de los suyos con los del rol. Al asumir un rol, adopta una identidad nueva. Sus permisos originales quedan apartados durante esa sesión, por lo que el diseño del rol debe incluir todo lo que la tarea necesita.

Recurra a un rol siempre que una carga de trabajo necesite acceso a AWS, cuando una cuenta deba actuar en otra o cuando las personas se autentiquen mediante un proveedor externo. En el examen, los roles son la respuesta a casi cualquier pregunta del tipo «¿cómo concedo acceso sin utilizar claves de larga duración?». Combinan una política de confianza (quién) con políticas de permisos (qué) para proporcionar un acceso seguro, temporal y auditable.

Un IAM role es una identidad sin credenciales que se asume para obtener permisos temporales de STS. Combina una trust policy (quién puede asumirlo) con permission policies (qué puede hacer). Los roles permiten el acceso de servicios, la delegación entre cuentas y la federación, y eliminan los secretos de larga duración. Al asumir un rol, su identidad se sustituye por la del rol durante la sesión.