# Tutoriales de IAM
Los siguientes tutoriales presentan procedimientos integrales completos para tareas comunes de AWS Identity and Access Management (IAM). Están pensados para un entorno de laboratorio, con los nombres de empresa ficticios, los nombres de usuario y así sucesivamente. Su finalidad es proporcionar orientación general. No deben utilizarse directamente en un entorno de producción sin antes realizar una revisión y adaptación exhaustivas para satisfacer las necesidades únicas del entorno de la organización.
**Topics**
+ [Delegación del acceso entre Cuentas de AWS mediante roles](tutorial_cross-account-with-roles.md)
+ [Crear una política administrada por el cliente](tutorial_managed-policies.md)
+ [Utilizar el control de acceso basado en atributos (ABAC)](tutorial_attribute-based-access-control.md)
+ [Permitir que los usuarios administren sus credenciales y la configuración de MFA](tutorial_users-self-manage-mfa-and-creds.md)
+ [Crear un IdP de SAML con CloudFormation](tutorial_saml-idp.md)
+ [Crear un rol federado de SAML con CloudFormation](tutorial_saml-federated-role.md)
+ [Crear un IdP y un rol federado de SAML con CloudFormation](tutorial_saml-idp-and-federated-role.md)
# Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM
**importante**
Las [prácticas recomendadas](best-practices.md) de IAM sugieren que exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder a AWS con credenciales temporales, en lugar de utilizar usuarios de IAM con credenciales a largo plazo. Para los [casos de uso específicos](gs-identities-iam-users.md) no compatibles con usuarios federados, recomendamos utilizar únicamente usuarios de IAM.
En este tutorial, se enseña cómo utilizar un rol para delegar el acceso a recursos en Cuentas de AWS diferentes llamadas cuentas de **destino** y de **origen**. Los recursos de una cuenta los comparte con usuarios de otra cuenta. Al configurar de esta forma un acceso entre cuentas, no deberá crear usuarios de IAM individuales en cada cuenta. Además, los usuarios no tendrán que cerrar sesión en una cuenta e iniciar sesión en otra cuenta para obtener acceso a los recursos en Cuentas de AWS diferentes. Cuando haya configurado el rol, aprenderá a utilizarlo en la Consola de administración de AWS, la AWS CLI y la API.
En este tutorial, la cuenta de **destino** administra los datos de la aplicación a los que acceden diferentes aplicaciones y equipos. En ambas cuentas, la información de las aplicaciones se almacena en buckets de Amazon S3. Usted administra los usuarios de IAM en la cuenta de **origen**, donde tiene dos roles de usuario de IAM: **desarrolladores** y **analistas**. Los desarrolladores y los analistas utilizan la cuenta de **origen** para generar datos compartidos por múltiples microservicios. Ambos roles tienen permisos para trabajar en la cuenta de origen y acceder a los recursos correspondientes. De vez en cuando, un desarrollador debe actualizar los datos compartidos en la cuenta de **destino**. Los desarrolladores almacenan estos datos en un bucket de Amazon S3 llamado `amzn-s3-demo-bucket-shared-container`.
Al final de este tutorial, dispone de lo siguiente:
+ Los usuarios en la cuenta de **origen** (la cuenta de confianza) tienen permitido asumir un rol específico en la cuenta de **destino**.
+ Un rol en la cuenta de **destino** (la cuenta de confianza) tiene permitido acceder a un bucket específico de Amazon S3.
+ El bucket `amzn-s3-demo-bucket-shared-container` en la cuenta de **destino**.
Los desarrolladores pueden usar el rol en la Consola de administración de AWS para acceder al bucket `amzn-s3-demo-bucket-shared-container` en la cuenta de **destino**. También pueden obtener acceso al bucket mediante llamadas a la API autenticadas con credenciales temporales que el rol proporciona. Si un analista intenta utilizar el rol de manera similar, obtendrá un error.
Este flujo de trabajo incluye tres pasos básicos:
**[Creación de un rol en la cuenta de destino](#tutorial_cross-account-with-roles-1)**
En primer lugar, la Consola de administración de AWS se utiliza para establecer una relación de confianza entre la cuenta de **destino** (número de ID 999999999999) y la cuenta de **origen** (número de ID 111111111111). Primero, cree un rol de IAM llamado *UpdateData*. Cuando cree el rol, defina la cuenta de **origen** como una entidad de confianza y especifique una política de permisos que permita a los usuarios de confianza actualizar el bucket `amzn-s3-demo-bucket-shared-container`.
**[Conceder acceso al rol](#tutorial_cross-account-with-roles-2)**
En este paso del tutorial, debe modificar la política del rol para denegar el acceso de los analistas al rol `UpdateData`. Como en este caso los analistas tienen acceso de usuario avanzado, debe *denegar* de forma explícita la posibilidad de que utilicen el rol.
**[Probar el acceso alternando roles](#tutorial_cross-account-with-roles-3)**
Por último, como desarrollador, utilice el rol `UpdateData` para actualizar el bucket `amzn-s3-demo-bucket-shared-container` en la cuenta de **destino**. Puede ver cómo obtener acceso al rol mediante la consola de AWS, la AWS CLI y la API.
## Consideraciones
Antes de utilizar roles de IAM para delegar el acceso a los recursos en Cuentas de AWS, es importante tener en cuenta lo siguiente:
+ No puede cambiar a un rol si inicia sesión como el Usuario raíz de la cuenta de AWS.
+ Los roles de IAM y las políticas basadas en recursos delegan el acceso entre cuentas solo dentro de una única partición. Suponga, por ejemplo, que tiene una cuenta en EE. UU. Oeste (Norte de California) en la partición estándar `aws`. También tiene una cuenta en China (Pekín) en la partición `aws-cn`. No puede utilizar una política de Amazon S3 basada en recursos en su cuenta en China (Pekín) para permitir el acceso a los usuarios de su cuenta `aws` estándar.
+ Puede utilizar AWS IAM Identity Center para facilitar el inicio de sesión único (SSO) en Cuentas de AWS externas (es decir, cuentas fuera de su AWS Organizations) mediante el lenguaje de marcado de aserción de seguridad (SAML). Para obtener más información, consulte [ Integración de Cuentas de AWS externas en AWS IAM Identity Center para la administración centralizada de accesos con facturación independiente mediante SAML 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en).
+ Puede asociar roles a recursos de AWS como instancias de Amazon EC2 o funciones de AWS Lambda. Para obtener más información, consulte [Crear un rol para delegar permisos a un servicio de AWS](id_roles_create_for-service.md).
+ Si desea que una aplicación asuma un rol en otra Cuenta de AWS, puede usar el AWS SDK para asumir roles entre cuentas. Para obtener más información, consulte [Autenticación y acceso](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) en la *Guía de referencia de las herramientas y los AWS SDK*.
+ El cambio de roles mediante la Consola de administración de AWS solo funciona con cuentas que no requieran un `ExternalId`. Por ejemplo, suponga que concede acceso a su cuenta a un tercero y requiere un `ExternalId` en un elemento `Condition` de su política de permisos. En ese caso, el tercero puede obtener acceso a su cuenta solo a través de la API de AWS o una herramienta de línea de comandos. El tercero no puede utilizar la consola, ya que debe proporcionar un valor para `ExternalId`. Para obtener más información sobre este caso, consulte [Acceder a las Cuentas de AWS que le pertenezcan a terceros](id_roles_common-scenarios_third-party.md) y [Cómo habilitar el acceso entre cuentas a la Consola de administración de AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) en el Blog de seguridad de AWS.
## Requisitos previos
En este tutorial se presupone que los elementos siguientes ya existen:
+ **Dos** Cuentas de AWS separadas que se pueden utilizar: una para representar la cuenta de **origen** y otra para representar la cuenta de **destino**.
+ Usuarios y roles en la cuenta de **origen**, creados y configurados de la siguiente manera:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ No necesita crear usuarios en la cuenta de **destino**.
+ Un bucket de Amazon S3 creado en la cuenta de **destino**. Puede denominarlo `amzn-s3-demo-bucket-shared-container` en este tutorial, pero debido a que los nombres de bucket de S3 deben ser únicos globalmente, deberá utilizar un bucket con otro nombre.
## Creación de un rol en la cuenta de destino
Puede permitir que los usuarios de una Cuenta de AWS obtengan acceso a los recursos de otra Cuenta de AWS. En este tutorial, crearemos un rol que define quién puede acceder a él y los permisos que otorga a los usuarios que lo asumen.
En este paso del tutorial, creará el rol en la cuenta de **destino** y especificará la cuenta de **origen** como entidad de confianza. También limitará los permisos del rol a un acceso de solo lectura y escritura para el bucket `amzn-s3-demo-bucket-shared-container`. Todos los que tengan permiso para utilizar el rol podrán leer y escribir en el bucket `shared-container`.
Para poder crear un rol, necesitará el *ID de cuenta* de la Cuenta de AWS de **origen**. Cada Cuenta de AWS tiene un identificador de ID de cuenta exclusivo asignado.
**Cómo obtener el ID de la Cuenta de AWS de origen**
1. Inicie sesión en la Consola de administración de AWS como administrador de la cuenta de **origen** y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En la consola de IAM, seleccione su nombre de usuario en la parte superior derecha de la barra de navegación. Normalmente tiene el siguiente aspecto: ***nombre\$1usuario*@*número\$1ID\$1cuenta\$1o\$1alias***.
En este caso, puede utilizar el ID de cuenta 111111111111 para la cuenta de **origen**. Sin embargo, debe utilizar un ID de cuenta válido si utiliza el escenario en su entorno de prueba.
**Cómo crear un rol en la cuenta de destino que pueda ser utilizado por la cuenta de origen**
1. Inicie sesión en la Consola de administración de AWS como administrador de la cuenta de **destino** y abra la consola de IAM.
1. Antes de crear el rol, prepare la política administrada que define los permisos para los requisitos del rol. Más tarde, en otro paso, la asociará al rol.
Debe configurar el acceso de lectura y escritura al bucket `amzn-s3-demo-bucket-shared-container`. Aunque AWS proporciona algunas políticas administradas por Amazon S3, ninguna proporciona acceso de lectura y escritura a un solo bucket de Amazon S3. En su lugar, puede crear su propia política.
En el panel de navegación, elija **Policies (Políticas)** y, a continuación, seleccione **Create policy (Crear política)**.
1. Seleccione la pestaña **JSON** y copie el texto del siguiente documento de política JSON. Pegue este texto en el cuadro de texto **JSON** y reemplace el ARN del recurso (`arn:aws:s3:::shared-container`) por el ARN real de su bucket de Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
La acción `ListAllMyBuckets` concede permiso para enumerar todos los buckets propiedad del remitente autenticado de la solicitud. El permiso `ListBucket` permite a los usuarios ver objetos en el bucket `amzn-s3-demo-bucket-shared-container`. Los permisos `GetObject`, `PutObject`, `DeleteObject` permiten a los usuarios ver, actualizar y eliminar contenido del bucket `amzn-s3-demo-bucket-shared-container`.
**nota**
Puede alternar entre las opciones **Visual** y **JSON** del editor en todo momento. No obstante, si realiza cambios o selecciona **Siguiente** en la opción **Visual** del editor, es posible que IAM reestructure la política, con el fin de optimizarla para el editor visual. Para obtener más información, consulte [Reestructuración de políticas](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. En la página **Revisar y crear**, escriba **read-write-app-bucket** como nombre de la política. Revise los permisos concedidos por la política y, a continuación, seleccione **Crear política** para guardar su trabajo.
La nueva política aparece en la lista de políticas administradas.
1. En el panel de navegación, seleccione **Roles** y, a continuación, seleccione **Crear rol**.
1. Elija el tipo de rol **Una Cuenta de AWS**.
1. En el campo **ID de cuenta**, ingrese el ID de la cuenta de **origen**.
En este tutorial, se utiliza el ID de cuenta de ejemplo **111111111111** para la cuenta de **origen**. Debe utilizar un ID de cuenta válido. Si utiliza un ID de cuenta que no es válido, como **111111111111**, IAM no le permitirá crear el nuevo rol.
Por ahora, no necesita exigir un ID externo ni solicitar a los usuarios que utilicen autenticación multifactor (MFA) para asumir el rol. Deje estas opciones desmarcadas. Para obtener más información, consulte [Autenticación multifactor de AWS en IAM](id_credentials_mfa.md).
1. Seleccione **Next: Permissions** (Siguiente: Permisos) para establecer los permisos asociados al rol.
1. Seleccione la casilla situada junto a la política que ha creado anteriormente.
**Sugerencia**
En **Filter** (Filtro), elija **Customer managed** (Administrado por el cliente) para filtrar la lista e incluir únicamente las políticas que creó. Esto ocultará las políticas creadas por AWS y facilitará en gran medida encontrar la política que necesita.
A continuación, elija **Siguiente**.
1. De manera opcional, agregue metadatos al rol al asociar etiquetas como pares de clave-valor. Para obtener más información acerca del uso de etiquetas en IAM, consulte [Etiquetas para recursos de AWS Identity and Access Management](id_tags.md).
1. (Opcional) En **Descripción**, ingrese una descripción para el nuevo rol.
1. Después de revisar el rol, seleccione **Create Role (Crear rol)**.
El rol `UpdateData` se muestra en la lista de roles.
Ahora debe obtener el nombre de recurso de Amazon (ARN) del rol, un identificador exclusivo del rol. Si modifica el rol de desarrollador en la cuenta de origen, debe especificar el ARN del rol de la cuenta de destino para conceder o denegar permisos.
**Cómo obtener el ARN de UpdateData**
1. En el panel de navegación de la consola de IAM, elija **Roles**.
1. En la lista de roles, elija el rol `UpdateData`.
1. En la sección **Summary (Resumen)** del panel de detalles, copie el valor de **Role ARN (ARN del rol)**.
La cuenta de destino tiene el ID de cuenta 999999999999, por lo que el ARN del rol es `arn:aws:iam::999999999999:role/UpdateData`. Asegúrese de proporcionar el ID real de la Cuenta de AWS para la cuenta de destino.
En este punto, ha establecido una relación de confianza entre la cuenta de **destino** y la cuenta de **origen**. Para ello, se creó un rol en la cuenta de **destino** que identifica a la cuenta de **origen** como entidad principal de confianza. También ha definido qué pueden hacer los usuarios que cambian al rol `UpdateData`.
A continuación, se procederá a modificar los permisos del rol de desarrollador.
## Conceder acceso al rol
En este punto, tanto los analistas como los desarrolladores tienen permisos que les permiten administrar los datos en la cuenta de **origen**. Estos son los pasos necesarios para agregar permisos que permitan cambiar al rol.
**Cómo modificar el rol de desarrolladores y permitirles asumir el rol UpdateData**
1. Inicie sesión como administrador en la cuenta de **origen** y abra la consola de IAM.
1. Seleccione **Roles** y, a continuación, elija **Desarrolladores**.
1. Elija la pestaña de **Permisos**, elija **Agregar permisos** y luego **Crear política insertada**.
1. Seleccione la pestaña **JSON**.
1. Agregue la siguiente declaración de política para permitir la acción `AssumeRole` en el rol `UpdateData` en la cuenta de destino. Asegúrese de reemplazar *DESTINATION-ACCOUNT-ID* en el elemento `Resource` por el ID de Cuenta de AWS real de la cuenta de destino.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
El efecto `Allow` permite de manera explícita al grupo de desarrolladores obtener acceso al rol `UpdateData` en la cuenta de destino. Todos los desarrolladores que intenten obtener acceso al rol lo consiguen.
1. Elija **Revisar política**.
1. Escriba un **Nombre**; por ejemplo, **allow-assume-S3-role-in-destination**.
1. Elija **Crear política**.
En la mayoría de los entornos, quizás no sea necesario el siguiente procedimiento. Si, por el contrario, usa permisos de PowerUserAccess, es posible que algunos grupos ya puedan cambiar de rol. A continuación, se detalla el procedimiento para agregar un permiso `"Deny"` al grupo de analistas, con el fin de asegurarse de que no puedan asumir el rol correspondiente. Si este procedimiento no es necesario en su entorno, le recomendamos que no lo agregue. Los permisos `"Deny"` hacen que el panorama general de los permisos sea más difícil de administrar y de entender. Utilice los permisos `"Deny"` solo cuando no tenga una opción mejor.
**Cómo modificar el rol de analista y denegarle el permiso para asumir el rol `UpdateData`**
1. Seleccione **Roles** y, a continuación, elija **Analistas**.
1. Elija la pestaña de **Permisos**, elija **Agregar permisos** y luego **Crear política insertada**.
1. Seleccione la pestaña **JSON**.
1. Añada la siguiente declaración de política para denegar la acción `AssumeRole` en el rol `UpdateData`. Asegúrese de reemplazar *DESTINATION-ACCOUNT-ID* en el elemento `Resource` por el ID de Cuenta de AWS real de la cuenta de destino.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
El efecto `Deny` deniega de manera explícita al grupo de analistas el acceso al rol `UpdateData` en la cuenta de destino. Todos los analistas que intenten obtener acceso al rol reciben un mensaje de acceso denegado.
1. Elija **Revisar política**.
1. Escriba un **Nombre**; por ejemplo, **deny-assume-S3-role-in-destination**.
1. Elija **Crear política**.
Ahora, el rol de desarrolladores tiene permisos para utilizar el rol `UpdateData` en la cuenta de destino. El rol de analistas no tiene permiso para utilizar el rol `UpdateData`.
A continuación, se muestra cómo David, un desarrollador, puede obtener acceso al bucket `amzn-s3-demo-bucket-shared-container` en la cuenta de destino. David puede obtener acceso al bucket desde la Consola de administración de AWS, la AWS CLI, o la API de AWS.
## Probar el acceso alternando roles
Después de completar los dos primeros pasos de este tutorial, dispondrá de un rol que concede acceso a un recurso en la cuenta de **destino**. También contará con un rol en la cuenta de **origen** que permite a los usuarios utilizar dicho rol. En este paso se explica cómo probar el cambio a este rol desde la Consola de administración de AWS, la AWS CLI, y la API de AWS.
Para obtener ayuda con los problemas comunes que pueden surgir cuando trabaja con roles de IAM, consulte [Solucionar problemas de roles de IAM](troubleshoot_roles.md).
### Cambio de roles (consola)
Si David necesita actualizar los datos de la cuenta de **destino** de la Consola de administración de AWS, puede hacerlo mediante la opción **Cambiar rol**. Indica el ID de cuenta o el alias, y el nombre del rol, y sus permisos cambian inmediatamente a los que están permitidos por el rol. Luego, podrá usar la consola para trabajar con el bucket `amzn-s3-demo-bucket-shared-container`, pero no podrá interactuar con otros recursos en la cuenta de **destino**. Mientras David utilice el rol, tampoco podrá hacer uso de sus privilegios de usuario avanzado en la cuenta de **origen**. Esto se debe a que no puede haber más de un conjunto de permisos en vigor a la vez.
Gracias a IAM, David puede entrar en la página **Switch Role** (Cambiar rol) de dos formas:
+ David recibe un enlace de su administrador que apunta a una configuración de Switch Role (Cambiar rol) predefinida. El enlace se proporciona al administrador en la página final del asistente **Create role (Crear rol)** y en la página **Role Summary (Resumen del rol)** a un rol con permisos entre cuentas. Si David elige este enlace, obtendrá acceso a la página **Switch Role (Cambiar rol)** con los campos **Account ID (ID de cuenta)** y **Role name (Nombre del rol)** ya completados. David solo tiene que elegir **Switch Roles (Cambiar roles)**.
+ El administrador no envía el enlace por correo electrónico, sino que envía los valores de **Account ID (ID de cuenta)** y **Role Name (Nombre del rol)**. Para cambiar de roles, David tiene que ingresar manualmente los valores. Esto se muestra en el procedimiento siguiente.
**Para asumir un rol**
1. David inicia sesión en la Consola de administración de AWS con su usuario habitual en la cuenta de **origen**.
1. Ellos eligen el vínculo que el administrador les envía. Esto lleva a David a la página **Switch Role** (Cambiar rol) con la información del ID de cuenta o alias y el nombre de rol ya completados.
—o bien—
David elige su nombre, en el menú Identity (Identidad), en la barra de navegación y, a continuación, elige **Switch Role** (Cambiar rol).
Si es la primera vez que David intenta obtener acceso a la página Switch Role (Cambiar rol) de esta manera, primero entrará a la página **Switch Role** (Cambiar rol) predeterminada. Esta página proporciona información adicional acerca de cómo el cambio de rol puede permitir a los usuarios para que administren recursos entre Cuentas de AWS. David debe hacer clic en **Switch Role** (Cambiar rol) en esta página para completar el resto de este procedimiento.
1. A continuación, para acceder al rol, David debe ingresar el número de ID de la cuenta de destino (`999999999999`) y el nombre del rol (`UpdateData`) de forma manual.
Además, David quiere monitorear qué roles y permisos asociados están activos actualmente en IAM. Para realizar un seguimiento de esta información, escribe `Destination` en el cuadro de texto **Nombre de visualización**, selecciona la opción de color rojo y, a continuación, elige **Cambiar rol**.
1. Ahora puede utilizar la consola de Amazon S3 para trabajar con el bucket de Amazon S3 o cualquier otro recurso sobre el que el rol `UpdateData` tenga permisos.
1. Al terminar, David puede volver a sus permisos originales. Para ello, deben elegir el nombre de visualización del rol de **destino** en la barra de navegación y, a continuación, seleccionar **Volver a David @ 111111111111**.
1. La próxima vez que David quiera cambiar de rol y seleccione el menú **Identidad** en la barra de navegación, verá que la entrada de destino aún está allí desde la última vez. Solo tiene que elegir esa entrada para cambiar de rol inmediatamente sin tener que volver a escribir el ID de cuenta y el nombre de rol.
### Cambio de roles (AWS CLI)
Si David necesita trabajar en la línea de comandos en el entorno de **destino**, puede hacerlo mediante la [AWS CLI](https://aws.amazon.com/cli/). Ejecuta el comando `aws sts assume-role` y pasa el ARN del rol para obtener las credenciales de seguridad temporales de dicho rol. Luego configura esas credenciales en las variables de entorno para que los comandos de la AWS CLI posteriores utilicen los permisos del rol. Aunque David asume el rol, no puede ejercer sus privilegios de usuario avanzado en la cuenta de **origen**, ya que solo puede estar en vigor un conjunto de permisos a la vez.
Tenga en cuenta que todas las claves de acceso y tokens solo son ejemplos y no se pueden utilizar tal y como se muestran. Tiene que sustituirlos por los valores adecuados de su entorno real.
**Para asumir un rol**
1. David abre una ventana de símbolo de sistema y confirma que el cliente de la AWS CLI está trabajando, ejecutando el comando:
```
aws help
```
**nota**
El entorno predeterminado de David utiliza las credenciales de usuario de `David` de su perfil predeterminado que creó con el comando `aws configure`. Para obtener más información, consulte [Configuración de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) en la *Guía del usuario de AWS Command Line Interface*.
1. Comienza el proceso de cambio de rol con la ejecución del siguiente comando para cambiar al rol `UpdateData` en la cuenta de **destino**. El administrador que ha creado el rol le proporcionó el ARN del rol. El comando necesita que indique también un nombre de sesión; para ello puede elegir cualquier texto.
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
Después, David ve lo siguiente en la salida:
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David ve los tres elementos que necesitan en la sección Credentials (Credenciales) de la salida.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David necesita configurar el entorno de la AWS CLI para utilizar estos parámetros en las llamadas posteriores. Para obtener información sobre las distintas formas de configurar sus credenciales, consulte [Configuración de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). No puede ejecutar el `aws configure`, ya que no admite la captura del token de sesión. Sin embargo, puede ingresar manualmente la información en un archivo de configuración. Dado que se trata de credenciales temporales con una fecha de vencimiento relativamente corta, es más fácil añadirlas al entorno de la sesión de la línea de comandos actual.
1. Para añadir los tres valores al entorno, David corta y pega la salida del paso anterior en los comandos siguientes. Puede interesarle cortar y pegar en un editor de texto sencillo para tratar los problemas de ajuste de línea de la salida del token de la sesión. Debe añadirse como una cadena única y larga, aunque se muestre con ajustes de línea para aportar mayor claridad.
En el siguiente ejemplo se muestran los comandos indicados en el entorno de Windows, donde "set" es el comando para crear una variable de entorno. En un equipo Linux o macOS, se utiliza el comando "export". Las demás partes del ejemplo son válidas en los tres entornos.
Para obtener más información sobre el uso de las herramientas para Windows Powershell, consulte [Cambiar a un rol de IAM (Herramientas para Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
En este punto, todos los comandos siguientes se ejecutan en los permisos del rol que las credenciales identifican. En el caso de David, el rol `UpdateData`.
**importante**
Puede guardar las opciones de configuración y las credenciales que utiliza con frecuencia en archivos que son mantenidos por la AWS CLI. Para obtener más información, consulte [Uso de archivos de configuración y credenciales existentes](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) en la *Guía del usuario de AWS Command Line Interface*.
1. Ejecute el comando para obtener acceso a los recursos de la cuenta de destino. En este ejemplo, David genera una lista del contenido de su bucket de S3 con el siguiente comando.
```
aws s3 ls s3://shared-container
```
Dado que los nombres de bucket de Amazon S3 son únicos universalmente, no es necesario especificar el ID de la cuenta que posee el bucket. Para obtener acceso a los recursos de otros servicios de AWS, consulte la documentación de la AWS CLI correspondiente a dicho servicio para informarse de los comandos y la sintaxis que son necesarios para hacer referencia a sus recursos.
### Uso de AssumeRole (API de AWS)
Cuando David necesita realizar una actualización en la cuenta de **destino** a través del código, llama a `AssumeRole` para asumir el rol `UpdateData`. La llamada devuelve credenciales temporales que puede utilizar para obtener acceso al bucket `amzn-s3-demo-bucket-shared-container` de la cuenta de **destino**. Con estas credenciales, David puede realizar llamadas a la API para actualizar el bucket `amzn-s3-demo-bucket-shared-container`. Sin embargo, no puede realizar llamadas a la API para obtener acceso a otros recursos de la cuenta de **destino**, aunque tenga permisos de usuario avanzado en la cuenta de **origen**.
**Para asumir un rol**
1. David llama a `AssumeRole` como parte de una aplicación. Deben especificar el ARN `UpdateData`: `arn:aws:iam::999999999999:role/UpdateData`.
La respuesta de la llamada `AssumeRole` incluye las credenciales temporales con un `AccessKeyId` y una `SecretAccessKey`. También incluye una hora de `Expiration` que indica cuándo caducan las credenciales y debe solicitar otras nuevas. Al configurar el encadenamiento de roles con el AWS SDK, muchos proveedores de credenciales actualizan de forma automática las credenciales antes de que caduquen.
1. Con las credenciales temporales, David realiza una llamada `s3:PutObject` para actualizar el bucket `amzn-s3-demo-bucket-shared-container`. Transfieren las credenciales a la llamada API como el parámetro `AuthParams`. Dado que las credenciales temporales del rol tienen acceso de solo lectura y escritura al bucket `amzn-s3-demo-bucket-shared-container`, se deniegan todas las demás acciones de la cuenta de destino.
Para obtener código de ejemplo (mediante Python), consulte [Cambiar a un rol de IAM (API de AWS)](id_roles_use_switch-role-api.md).
## Recursos adicionales
Los siguientes recursos pueden ser de ayuda para obtener más información sobre los temas tratados en este tutorial:
+ Para obtener más información acerca de los usuarios de IAM, consulte [Identidades de IAM](id.md).
+ Para obtener más información acerca los buckets de Amazon S3, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service*.
+ Consulte [¿Qué es Analizador de acceso de IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles.
## Resumen
Acaba de completar el tutorial de acceso entre varias cuentas mediante API. Ha creado un rol para establecer una relación de confianza con otra cuenta y definir qué acciones pueden realizar entidades de confianza. Luego, modificó una política de rol para controlar qué usuarios de IAM pueden acceder al rol. Como resultado, los desarrolladores de la cuenta de **origen** pueden realizar actualizaciones en el bucket `amzn-s3-demo-bucket-shared-container` de la cuenta de **destino** mediante el uso de credenciales temporales.
# Tutorial de IAM: crear y asociar su primera política administrada por el cliente
En este tutorial, utilice la Consola de administración de AWS para crear una [política administrada por el cliente](access_policies_managed-vs-inline.md#customer-managed-policies) y asociar dicha política a un usuario de IAM de su Cuenta de AWS. La política que cree permite a un usuario de prueba de IAM iniciar sesión directamente en la Consola de administración de AWS con permisos de solo lectura.
Este flujo de trabajo incluye tres pasos básicos:
**[Paso 1: crear la política](#step1-create-policy)**
De forma predeterminada, los usuarios de IAM no tienen permisos para realizar ninguna actividad. No pueden obtener acceso a Management Console de AWS ni administrar los datos, a no ser que usted lo permita. En este paso, debe crear una política administrada por el cliente que permita a cualquier usuario asociado iniciar sesión en la consola.
**[Paso 2: asociar la política](#step2-attach-policy)**
Al asociar una política a un usuario, el usuario hereda todos los permisos de acceso asociados a dicha política. En este paso, debe asociar la nueva política a una cuenta de usuario de prueba.
**[Paso 3: Probar el acceso de los usuarios](#step3-test-access)**
Una vez que haya asociado la política, puede iniciar sesión como el usuario y probar la política.
## Requisitos previos
Para realizar los pasos en este tutorial, tendrá que ya tiene lo siguiente:
+ Una Cuenta de AWS en la que puede iniciar sesión como usuario de IAM con permisos administrativos.
+ Un usuario de prueba de IAM que no tenga permisos asignados ni suscripciones a grupos, tal y como se indica a continuación:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_managed-policies.html)
## Paso 1: crear la política
En este paso, debe crear una política administrada por el cliente que permita a cualquier usuario asociado iniciar sesión en la Consola de administración de AWS con acceso de solo lectura a los datos de IAM.
**Para crear la política para un usuario de prueba**
1. Inicie sesión en la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) con un usuario que tenga permisos de administrador.
1. En el panel de navegación, seleccione **Políticas**.
1. En el panel de contenido, elija **Create policy (Crear política)**.
1. Seleccione la opción **JSON** y copie el texto del siguiente documento de política de JSON. Pegue el texto en el cuadro de texto **JSON**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
```
------
1. Resuelva las advertencias de seguridad, errores o advertencias generales generadas durante la [validación de política](access_policies_policy-validator.md) y luego elija **Siguiente**.
**nota**
Puede alternar entre las opciones **Visual** y **JSON** del editor en todo momento. Sin embargo, si realiza cambios o elige **Revisar política** en la pestaña **Editor Visual**, IAM podría reestructurar la política para optimizarla para el editor visual. Para obtener más información, consulte [Reestructuración de políticas](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. En la página **Revisar y crear**, escriba **UsersReadOnlyAccessToIAMConsole** como nombre de la política. Revise los permisos concedidos por la política y, a continuación, seleccione **Crear política** para guardar su trabajo.
La nueva política aparece en la lista de las políticas administradas y está lista para asociar.
## Paso 2: asociar la política
A continuación, debe asociar la política que acaba de crear al usuario de IAM de prueba.
**Para asociar la política a un usuario de prueba**
1. En la consola de IAM, en el panel de navegación, elija **Políticas**.
1. En la parte superior de la lista de políticas, en el cuadro de búsqueda, comience a escribir **UsersReadOnlyAccesstoIAMConsole** hasta que pueda ver la política. Después, seleccione el botón de radio situado junto a **UsersReadOnlyAccessToIAMConsole** en la lista.
1. Elija el botón **Actions** (Acciones) y, a continuación, elija **Attach** (Asociar).
1. En las entidades de IAM, seleccione la opción para filtrar por **Usuarios**.
1. En el cuadro de búsqueda, comience a escribir **PolicyUser** hasta que el usuario aparezca en la lista. A continuación, marque la casilla situada junto a ese usuario en la lista.
1. Elija **Asociar política**.
Ha asociado la política al usuario de prueba de IAM, lo que significa que el usuario ahora tiene acceso de solo lectura a la consola de IAM.
## Paso 3: Probar el acceso de los usuarios
En este tutorial, le recomendamos que pruebe el acceso iniciando sesión como usuario de prueba para comprobar lo que los usuarios ven y cómo.
**Para probar el acceso iniciando sesión en la cuenta de usuario de prueba**
1. Inicie sesión en la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) con su usuario `PolicyUser` de prueba.
1. Examine las páginas de la consola e intente crear un nuevo usuario o grupo. Tenga en cuenta que `PolicyUser` puede mostrar datos, pero no puede crear ni modificar datos de IAM existentes.
## Recursos relacionados
Para obtener información relacionada, consulte los recursos siguientes:
+ [Políticas administradas y políticas insertadas](access_policies_managed-vs-inline.md)
+ [Control del acceso del usuario de IAM a la Consola de administración de AWS](console_controlling-access.md)
## Resumen
Acaba de completar correctamente todos los pasos necesarios para crear y asociar una política administradas por el cliente. Como resultado, puede iniciar sesión en la consola de IAM con su cuenta de prueba para ver cómo es la experiencia de los usuarios.
# Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas
El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos. En AWS, estos atributos se denominan *etiquetas*. Puede asociar etiquetas a recursos de IAM, incluidas entidades de IAM (usuarios o roles) y recursos de AWS. Puede definir políticas que utilicen claves de condición de etiqueta para conceder permisos a sus entidades principales en función de sus etiquetas. Cuando utiliza etiquetas para controlar el acceso a sus recursos de AWS, permite que sus equipos y recursos crezcan con menos cambios en las políticas de AWS. Las políticas de ABAC son más flexibles que las políticas tradicionales de AWS, en las que debe enumerar cada recurso individual. Para obtener más información acerca de ABAC y su ventaja sobre las políticas tradicionales, consulte [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md).
**nota**
Debe pasar un solo valor para cada etiqueta de sesión. AWS Security Token Service no admite etiquetas de sesión de varios valores.
**Topics**
+ [Información general del tutorial](#tutorial_attribute-based-access-control-overview)
+ [Requisitos previos](#tutorial_abac_prereqs)
+ [Paso 1: crear usuarios de prueba](#tutorial_abac_step1)
+ [Paso 2: crear la política de ABAC](#tutorial_abac_step2)
+ [Paso 3: crear roles](#tutorial_abac_step3)
+ [Paso 4: Probar la creación de secretos](#tutorial_abac_step4)
+ [Paso 5: Probar la visualización de secretos](#tutorial_abac_step5)
+ [Paso 6: Probar la escalabilidad](#tutorial_abac_step6)
+ [Paso 7: Probar la actualización y eliminación de secretos](#tutorial_abac_step7)
+ [Resumen](#tutorial-abac-summary)
+ [Recursos relacionados](#tutorial_abac_related)
+ [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md)
## Información general del tutorial
En este tutorial se muestra cómo crear y probar una política que permite a los roles de IAM con etiquetas principales obtener acceso a los recursos con etiquetas coincidentes. Cuando una entidad principal realiza una solicitud a AWS, sus permisos se conceden en función de si la entidad principal y las etiquetas de recursos coinciden. Esta estrategia permite a las personas ver o editar solo los recursos de AWS necesarios para sus trabajos.
**Escenario**
Supongamos que es un desarrollador líder de una gran empresa denominada Empresa Ejemplo y que es un administrador de IAM con experiencia. Está familiarizado con la creación y administración de usuarios, roles y políticas de IAM. Quiere asegurarse de que los ingenieros de desarrollo y los miembros del equipo de control de calidad puedan obtener acceso a los recursos que necesitan. También necesita una estrategia que se escale a medida que su empresa crezca.
Puede elegir utilizar etiquetas de recursos de AWS y etiquetas principales de rol IAM para implementar una estrategia de ABAC para los servicios que la admitan, que comienzan por AWS Secrets Manager. Para saber qué servicios admiten la autorización basada en etiquetas, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md). Para obtener información sobre las claves de condición de etiquetado que pueden utilizarse en políticas con cada acción y recurso de servicio, consulte [Acciones, recursos y claves de condición para servicios de AWS](reference_policies_actions-resources-contextkeys.html). Puede configurar su proveedor de identidad web o basado en SAML para que pase las [etiquetas de sesión](id_session-tags.md) a AWS. Cuando los empleados se federan en AWS, sus atributos se aplican a su entidad principal resultante en AWS. Entonces puede utilizar ABAC para permitir o denegar permisos basados en esos atributos. Para saber cómo el uso de etiquetas de sesión con una identidad federada SAML difiere de este aprendizaje, consulte [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md).
Los miembros del equipo de ingeniería y control de calidad están en el proyecto **Pegasus** o **Unicorn**. Puede elegir los siguientes valores de etiqueta de equipo y proyecto de 3 caracteres:
+ `access-project` = `peg` para el proyecto **Pegasus**
+ `access-project` = `uni` para el proyecto **Unicorn**
+ `access-team` = `eng` para el equipo de ingeniería
+ `access-team` = `qas` para el equipo de control de calidad
Además, puede solicitar la etiqueta de asignación de costos `cost-center` para habilitar los informes de facturación personalizados de AWS. Para obtener más información, consulte [Uso de etiquetas de asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) en la *Guía del usuario de Administración de facturación y costos de AWS*.
**Resumen de decisiones clave**
+ Los empleados inician sesión con las credenciales de usuario de IAM y, a continuación, asumen el rol de IAM para su equipo y proyecto. Si su empresa tiene su propio sistema de identidad, puede configurar la federación para permitir a los empleados asumir un rol sin usuarios de IAM. Para obtener más información, consulte [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md).
+ La misma política se asocia a todos los roles. Las acciones se permiten o deniegan en función de las etiquetas.
+ Los empleados pueden crear nuevos recursos, pero solo si asocian las mismas etiquetas al recurso que se aplica a su rol. Esto garantiza que los empleados puedan ver el recurso después de crearlo. Ya no es necesario que los administradores actualicen las políticas con el ARN de los nuevos recursos.
+ Los empleados pueden leer los recursos que pertenecen a su equipo, independientemente del proyecto.
+ Los empleados pueden actualizar y eliminar recursos propiedad de su propio equipo y proyecto.
+ Los administradores de IAM pueden agregar un nuevo rol para nuevos proyectos. Pueden crear y etiquetar un nuevo usuario de IAM para permitir el acceso al rol adecuado. Los administradores no tienen que editar una política para admitir un nuevo proyecto o miembro del equipo.
En este tutorial, etiquetará cada recurso, etiquetará los roles del proyecto y añadirá políticas a los roles para permitir el comportamiento descrito anteriormente. La política resultante permite a los roles `Create`, `Read`, `Update` y `Delete` acceso a los recursos que están etiquetados con las mismas etiquetas de proyecto y equipo. La política también permite el acceso entre proyectos a `Read` para los recursos que están etiquetados con el mismo equipo.
![\[En el diagrama, se muestran dos proyectos en los que los roles están limitados al acceso de solo lectura fuera del proyecto, mientras que tienen permisos para crear, leer, actualizar y eliminar recursos en su propio proyecto.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png)
## Requisitos previos
Para realizar los pasos en este tutorial, deberá disponer de lo siguiente:
+ Una Cuenta de AWS en la que puede iniciar sesión como usuario con permisos administrativos.
+ Su ID de cuenta de 12 dígitos, que utilizará para crear los roles en el paso 3.
Para encontrar el número de ID de cuenta de AWS mediante la Consola de administración de AWS, seleccione **Support (Soporte)** en la barra de navegación en la parte superior derecha y, a continuación, elija **Support Center (Centro de soporte)**. El número de cuenta (ID) aparece en el panel de navegación de la izquierda.
![\[Página central de Soporte que muestra el número de cuenta.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/account-id-support-center.console.png)
+ Experimente creando y editando usuarios, roles y políticas de IAM en la Consola de administración de AWS. Sin embargo, si necesita ayuda para recordar un proceso de administración de IAM, este tutorial proporciona enlaces en los que puede ver las instrucciones paso a paso.
## Paso 1: crear usuarios de prueba
Para realizar pruebas, cree cuatro usuarios de IAM con permisos para asumir roles con las mismas etiquetas. Esto facilita añadir más usuarios a sus equipos. Al etiquetar los usuarios, estos obtienen acceso automáticamente para asumir el rol correcto. No es necesario agregar los usuarios a la política de confianza del rol si solo trabajan en un proyecto y en un equipo.
1. Cree la siguiente política administrada por el cliente denominada `access-assume-role`. Para obtener más información acerca de la creación de un política JSON, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start).
**Política de ABAC: asume cualquier rol de ABAC, pero solo cuando coinciden las etiquetas de usuario y rol.**
La siguiente política permite a un usuario asumir cualquier rol de su cuenta con el prefijo de nombre `access-`. El rol también debe estar etiquetado con las mismas etiquetas de proyecto, equipo y centro de costos que el usuario.
Para utilizar esta política, sustituya el *texto del marcador de posición en cursiva* por la información de la cuenta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/access-*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
```
------
Para escalar este tutorial a un gran número de usuarios, puede asociar la política a un grupo y añadir cada usuario al grupo. Para obtener más información, consulte [Creación de grupos de IAM](id_groups_create.md) y [Edición de usuarios de grupos de IAM](id_groups_manage_add-remove-users.md).
1. Cree los siguientes usuarios de IAM, asocie la política de permisos `access-assume-role`. Asegúrese de seleccionar **Conceder acceso de usuario a la Consola de administración de AWS** y, luego, agregue las siguientes etiquetas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Paso 2: crear la política de ABAC
Cree la siguiente política con el nombre **access-same-project-team**. Añadirá esta política a los roles en un paso posterior. Para obtener más información acerca de la creación de un política JSON, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start).
Para obtener más políticas que puede adaptar para este tutorial, consulte las siguientes páginas:
+ [Control del acceso para entidades principales de IAM](access_iam-tags.md#access_iam-tags_control-principals)
+ [Amazon EC2: permite iniciar o detener instancias EC2 que un usuario haya etiquetado, mediante programación y en la consola](reference_policies_examples_ec2_tag-owner.md)
+ [EC2: iniciar o detener instancias basándose en etiquetas de recursos y principal coincidentes](reference_policies_examples_ec2-start-stop-match-tags.md)
+ [EC2: iniciar o detener instancias en función de las etiquetas](reference_policies_examples_ec2-start-stop-tags.md)
+ [IAM: asumir funciones que tienen una etiqueta específica](reference_policies_examples_iam-assume-tagged-role.md)
**Política de ABAC: acceso a los recursos de Secrets Manager solo cuando coinciden las etiquetas principal y de recursos**
La siguiente política permite a las entidades principales crear, leer, editar y eliminar recursos, pero solo cuando dichos recursos están etiquetados con los mismos pares clave-valor que la entidad principal. Cuando una entidad principal crea un recurso, debe añadir etiquetas `access-project`, `access-team` y `cost-center` con valores que coincidan con las etiquetas de la entidad principal. La política también permite añadir etiquetas `Name` u `OwnedBy` opcionales.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
},
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}
```
------
**Qué hace esta política?**
+ La instrucción `AllActionsSecretsManagerSameProjectSameTeam` permite todas las acciones de este servicio en todos los recursos relacionados, pero solo si las etiquetas de los recursos coinciden con las etiquetas principales. Al agregar `"Action": "secretsmanager:*"` a la política, la política crece a medida que Secrets Manager crece. Si Secrets Manager añade una nueva operación de API, no es necesario que agregue dicha acción a la instrucción. La instrucción implementa el ABAC utilizando tres bloques de condición. La solicitud solo se permite si los tres bloques devuelven true.
+ El primer bloque de condición de esta instrucción devuelve true si las claves de etiqueta especificadas están presentes en el recurso y sus valores coinciden con las etiquetas de la entidad principal. Este bloque devuelve false para etiquetas no coincidentes o para acciones que no admiten el etiquetado de recursos. Para saber qué acciones no permite este bloque, consulte [Claves de condición, recursos y acciones de AWS Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html). En dicha página se muestra que las acciones realizadas en el tipo de recurso [https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) admiten la clave de condición `secretsmanager:ResourceTag/tag-key`. Algunas [acciones de Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) no admiten ese tipo de recurso, incluidas `GetRandomPassword` y `ListSecrets`. Debe crear instrucciones adicionales para permitir esas acciones.
+ El segundo bloque de condición devuelve true si todas las claves de etiqueta pasadas en la solicitud se incluyen en la lista especificada. Esto se realiza utilizando `ForAllValues` con el operador de condición `StringEquals`. Si no se pasa ninguna clave ni subconjunto del conjunto de claves, la condición se vuelve verdadera. Esto permite operaciones `Get*` que no permiten pasar etiquetas en la solicitud. Si el solicitante incluye una clave de etiqueta que no está en la lista, la condición devuelve false. Cada clave de etiqueta que se transfiere en la solicitud debe coincidir con un miembro de esta lista. Para obtener más información, consulte [Operadores de conjunto para claves de contexto multivalor](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ El tercer bloque de condición devuelve true si la solicitud admite la transferencia de etiquetas, si las tres etiquetas están presentes y si coinciden con los valores de etiqueta principal. Este bloque también devuelve true si la solicitud no admite la transferencia de etiquetas. Esto se debe a [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) en el operador de condición. El bloque devuelve false si no se pasa ninguna etiqueta durante una acción que lo admite, o si las claves y los valores de la etiqueta no coinciden.
+ La instrucción `AllResourcesSecretsManagerNoTags` permite las acciones `GetRandomPassword` y `ListSecrets` que la primera instrucción no permite.
+ La instrucción `ReadSecretsManagerSameTeam` permite operaciones de solo lectura si la entidad principal está etiquetada con la misma etiqueta de equipo de acceso que el recurso. Esto está permitido independientemente del proyecto o de la etiqueta del centro de costos.
+ La instrucción `DenyUntagSecretsManagerReservedTags` deniega las solicitudes para eliminar de Secrets Manager etiquetas con claves que comienzan por "access-". Estas etiquetas se utilizan para controlar el acceso a los recursos, por tanto, si se eliminan etiquetas se podrían eliminar permisos.
+ La instrucción `DenyPermissionsManagement` deniega el acceso para crear, editar o eliminar políticas basadas en recursos de Secrets Manager. Estas políticas se pueden utilizar para cambiar los permisos del secreto.
**importante**
Esta política utiliza una estrategia para permitir todas las acciones de un servicio, pero deniega explícitamente las acciones de modificación de permisos. Si se deniega una acción, se anula cualquier otra política que permita a la entidad principal realizar dicha acción. Esto puede tener resultados no deseados. Como práctica recomendada, utilice denegaciones explícitas solo cuando no haya ninguna circunstancia que deba permitir dicha acción. De lo contrario, permita una lista de acciones individuales y las acciones no deseadas se deniegan de forma predeterminada.
## Paso 3: crear roles
Cree los siguientes roles de IAM y asocie la política **access-same-project-team** creada en el paso anterior. Para obtener más información sobre cómo crear un rol de IAM, consulte [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md). Si decide utilizar la federación en lugar de usuarios y roles de IAM, consulte [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md).
| Función de trabajo | Nombre de rol | Etiquetas de roles | Descripción del rol |
| --- | --- | --- | --- |
| Ingeniería del proyecto Pegasus | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | Permite a los ingenieros leer todos los recursos de ingeniería y crear y administrar los recursos de ingeniería de Pegasus. |
| Control de calidad del proyecto Pegasus | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | Permite al equipo de control de calidad leer todos los recursos de control de calidad y crear y administrar todos los recursos de control de calidad de Pegasus. |
| Ingeniería del proyecto Unicorn | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | Permite a los ingenieros leer todos los recursos de ingeniería y crear y administrar los recursos de ingeniería de Unicorn. |
| Control de calidad del proyecto Unicorn | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | Permite al equipo de control de calidad leer todos los recursos de control de calidad y crear y administrar todos los recursos de control de calidad de Unicorn. |
## Paso 4: Probar la creación de secretos
La política de permisos asociada a los roles permite a los empleados crear secretos. Esto solo se permite si el secreto está etiquetado con su proyecto, equipo y centro de costos. Confirme que sus permisos funcionan según lo previsto iniciando sesión como usuarios, asumiendo el rol correcto y probando la actividad en Secrets Manager.
**Para probar la creación de un secreto con y sin las etiquetas necesarias**
1. En la ventana principal del navegador, mantenga la sesión iniciada como usuario administrador para que pueda revisar los usuarios, los roles y las políticas en IAM. Utilice una ventana de incógnito del navegador o un navegador independiente para las pruebas. Ahí, inicie sesión como usuario de IAM `access-Arnav-peg-eng` en la consola de Secrets Manager en [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).
1. Intente cambiar al rol `access-uni-engineering`.
Esta operación falla porque los valores de la etiqueta `access-project` y `cost-center` no coinciden con el usuario `access-Arnav-peg-eng` y el rol `access-uni-engineering`.
Para obtener más información acerca del cambio de roles en la Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md)
1. Cambie al rol `access-peg-engineering`.
1. Almacene un nuevo secreto con la siguiente información. Para obtener información sobre cómo almacenar un secreto, consulte [Creación de un secreto básico](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) en la *Guía del usuario de AWS Secrets Manager*.
**importante**
Secrets Manager muestra avisos indicando que no tiene permisos para servicios de AWS adicionales que funcionan con Secrets Manager. Por ejemplo, para crear credenciales para una base de datos de Amazon RDS, debe tener permiso para describir instancias de RDS, clústeres de RDS y clústeres de Amazon Redshift. Puede ignorar estas alertas, ya que en este tutorial no está utilizando estos servicios de AWS específicos.
1. En la sección **Select secret type (Seleccionar tipo de secreto)**, elija **Other type of secrets (Otro tipo de secretos)**. En los dos cuadros de texto, escriba `test-access-key` y `test-access-secret`.
1. Escriba `test-access-peg-eng` en el campo **Secret name (Nombre del secreto)**.
1. Añada diferentes combinaciones de etiquetas de la siguiente tabla y vea el comportamiento esperado.
1. Elija **Store (Almacenar)** para intentar crear el secreto. Cuando se produzca un error en el almacenamiento, vuelva a las páginas de la consola de Secrets Manager anteriores y utilice el siguiente conjunto de etiquetas de la siguiente tabla. El último conjunto de etiquetas está permitido y creará correctamente el secreto.
En la siguiente tabla, se muestra las combinaciones de etiquetas ABAC para el rol `test-access-peg-eng`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. Cierre la sesión y repita los tres primeros pasos de este procedimiento para cada uno de los siguientes roles y valores de etiqueta. En el cuarto paso de este procedimiento, pruebe cualquier conjunto de etiquetas que faltan, etiquetas opcionales, etiquetas no permitidas y valores de etiqueta no válidos que elija. A continuación, utilice las etiquetas necesarias para crear un secreto con las siguientes etiquetas y nombre.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Paso 5: Probar la visualización de secretos
La política que ha adjuntado a cada rol permite a los empleados ver cualquier secreto etiquetado con su nombre de equipo, independientemente de su proyecto. Confirme que sus permisos funcionan según lo previsto probando los roles en Secrets Manager.
**Para probar la visualización de un secreto con y sin las etiquetas requeridas**
1. Inicie sesión como uno de los siguientes usuarios de IAM:
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
1. Cambie al rol coincidente:
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-uni-quality-assurance`
Para obtener más información acerca del cambio de roles en la Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md).
1. En el panel de navegación de la izquierda, elija el icono de menú para ampliar el menú y, a continuación, elija **Secrets (Secretos)**.
1. Debería ver los cuatro secretos en la tabla, independientemente del rol actual. Esto se espera porque la política con el nombre `access-same-project-team` permite la acción `secretsmanager:ListSecrets` para todos los recursos.
1. Elija el nombre de uno de los secretos.
1. En la página de detalles del secreto, las etiquetas de su rol determinan si puede ver el contenido de la página. Compare el nombre de su rol con el nombre de su secreto. Si comparten el mismo nombre de equipo, las etiquetas `access-team` coinciden. Si no coinciden, el acceso se deniega.
En la siguiente tabla, se muestra el comportamiento de visualización de secretos de ABAC para cada rol.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. En la parte superior de la página, elija **Secrets (Secretos)** para volver a la lista de secretos. Repita los pasos de este procedimiento utilizando diferentes roles para probar si puede ver cada uno de los secretos.
## Paso 6: Probar la escalabilidad
Un motivo importante para utilizar el control de acceso basado en atributos (ABAC) sobre el control de acceso basado en roles (RBAC) es la escalabilidad. A medida que su empresa añade nuevos proyectos, equipos o personas a AWS, no es necesario actualizar sus políticas basadas en ABAC. Por ejemplo, supongamos que la Empresa Ejemplo está financiando un nuevo proyecto, con un código con el nombre **Centaur**. Un ingeniero llamado Saanvi Sarkar será el ingeniero jefe de **Centaur** y continuará trabajando en el proyecto **Unicorn** . Saanvi también revisará el trabajo del proyecto **Peg**. También hay varios ingenieros recién contratados, incluido Nikhil Jayashankar, que trabajará solo en el proyecto **Centaur**.
**Para añadir el nuevo proyecto a AWS**
1. Inicie sesión como usuario administrador de IAM y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación de la izquierda, seleccione **Roles** y añada un rol de IAM con el nombre `access-cen-engineering`. Asocie la política de permisos **access-same-project-team** al rol y agregue las siguientes etiquetas de rol:
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. En el panel de navegación de la izquierda, elija **Usuarios**.
1. Agregue un nuevo usuario denominado `access-Nikhil-cen-eng`, asocie la política denominada `access-assume-role` y agregue las siguientes etiquetas de usuario.
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. Utilice los procedimientos de [Paso 4: Probar la creación de secretos](#tutorial_abac_step4) y [Paso 5: Probar la visualización de secretos](#tutorial_abac_step5). En otra ventana del navegador, pruebe que Nikhil solo puede crear secretos de ingeniería de **Centaur** y que puede ver todos los secretos de ingeniería.
1. En la ventana principal del navegador en la que ha iniciado sesión como administrador, elija el usuario `access-Saanvi-uni-eng`.
1. En la pestaña **Permissions (Permisos )**, elimine la política de permisos **access-assume-role**.
1. Añada la siguiente política insertada denominada `access-assume-specific-roles`. Para obtener más información acerca de cómo añadir una política insertada a un usuario, consulte [Para integrar una política insertada de un usuario o un rol (consola)](access_policies_manage-attach-detach.md#embed-inline-policy-console).
**Política de ABAC: asumir solo roles específicos**
Esta política permite a Saanvi asumir los roles de ingeniería de los proyectos **Pegasus** y **Centaur**. Es necesario crear esta política personalizada porque IAM no admite etiquetas con varios valores. No puede etiquetar al usuario de Saanvi con `access-project` = `peg` y `access-project` = `cen`. Además, el modelo de autorización de AWS no puede coincidir con ambos valores. Para obtener más información, consulte [Reglas para etiquetar en IAM y AWS STS](id_tags.md#id_tags_rules). En su lugar, debe especificar manualmente los dos roles que puede asumir.
Para utilizar esta política, sustituya el *texto del marcador de posición en cursiva* por la información de la cuenta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/access-peg-engineering",
"arn:aws:iam::111122223333:role/access-cen-engineering"
]
}
]
}
```
------
1. Utilice los procedimientos de [Paso 4: Probar la creación de secretos](#tutorial_abac_step4) y [Paso 5: Probar la visualización de secretos](#tutorial_abac_step5). En otra ventana del navegador, confirme que Saanvi puede asumir ambos roles. Compruebe que solo puede crear secretos para su proyecto, equipo y centro de costos, en función de las etiquetas del rol. Confirme también que puede ver detalles sobre cualquier secreto propiedad del equipo de ingeniería, incluidos los que acaba de crear.
## Paso 7: Probar la actualización y eliminación de secretos
La política `access-same-project-team` asociada a los roles permite a los empleados actualizar y eliminar los secretos etiquetados con su proyecto, equipo y centro de costos. Confirme que sus permisos funcionan según lo previsto probando los roles en Secrets Manager.
**Para probar la actualización y eliminación de un secreto con y sin las etiquetas requeridas**
1. Inicie sesión como uno de los siguientes usuarios de IAM:
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
+ `access-Nikhil-cen-eng`
1. Cambie al rol coincidente:
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-peg-quality-assurance`
+ `access-cen-engineering`
Para obtener más información acerca del cambio de roles en la Consola de administración de AWS, consulte [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md).
1. Para cada rol, intente actualizar la descripción del secreto y, a continuación, intente eliminar los siguientes secretos. Para obtener más información, consulte [Modificación de un secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) y [Eliminación y restauración de un secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) en la *Guía del usuario de AWS Secrets Manager*.
En la siguiente tabla, se muestra el comportamiento de actualización y eliminación de secretos de ABAC para cada rol.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Resumen
Ha completado correctamente todos los pasos necesarios para utilizar etiquetas para el control de acceso basado en atributos (ABAC). Ha aprendido a definir una estrategia de etiquetado. Ha aplicado dicha estrategia a sus entidades principales y recursos. Ha creado y aplicado una política que aplica la estrategia para Secrets Manager. También ha aprendido que ABAC se escala fácilmente cuando añade nuevos proyectos y miembros del equipo. Como resultado, puede iniciar sesión en la consola de IAM con sus roles de prueba y experimentar cómo utilizar etiquetas para ABAC en AWS.
**nota**
Ha agregado políticas que permiten acciones solo en determinadas condiciones. Si aplica una política diferente a los usuarios o roles que tiene permisos más amplios, es posible que las acciones no se limiten a requerir el etiquetado. Por ejemplo, si concede a un usuario permisos administrativos completos mediante la política administrada por `AdministratorAccess` AWS, estas políticas no restringen ese acceso. Para obtener más información acerca de cómo se determinan los permisos cuando se aplican varias políticas, consulte [Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
## Recursos relacionados
Para obtener información relacionada, consulte los recursos siguientes:
+ [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md)
+ [Claves de contexto de condición globales de AWS](reference_policies_condition-keys.md)
+ [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md)
+ [Etiquetas para recursos de AWS Identity and Access Management](id_tags.md)
+ [Control de acceso a los recursos de AWS mediante etiquetas](access_tags.md)
+ [Cambiar de usuario a rol de IAM (consola)](id_roles_use_switch-role-console.md)
+ [Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC](tutorial_abac-saml.md)
Para obtener información sobre cómo monitorear las etiquetas en su cuenta, consulte [Monitorear los cambios de etiquetas en recursos de AWS con flujos de trabajo sin servidor y Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/).
# Tutorial de IAM: utilizar etiquetas de sesión SAML para ABAC
El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos. En AWS, estos atributos se denominan etiquetas. Puede asociar etiquetas a recursos de IAM, incluidas entidades de IAM (usuarios o roles) y recursos de AWS. Cuando las entidades se utilizan para realizar solicitudes de AWS, se convierten en entidades principales y esas entidades incluyen etiquetas.
También puede pasar [etiquetas de sesión](id_session-tags.md) al asumir un rol o federar un usuario. A continuación, puede definir políticas que utilicen claves de condición de etiqueta para conceder permisos a sus entidades principales en función de sus etiquetas. Cuando utiliza etiquetas para controlar el acceso a sus recursos de AWS, permite que sus equipos y recursos crezcan con menos cambios en las políticas de AWS. Las políticas de ABAC son más flexibles que las políticas tradicionales de AWS, en las que debe enumerar cada recurso individual. Para obtener más información acerca de ABAC y su ventaja sobre las políticas tradicionales, consulte [Definición de permisos en función de los atributos con la autorización de ABAC](introduction_attribute-based-access-control.md).
Si su empresa utiliza un proveedor de identidades (IdP) basado en SAML para administrar las identidades de usuarios corporativos, puede utilizar atributos SAML para un control de acceso detallado en AWS. Los atributos pueden incluir identificadores de centros de coste, direcciones de correo electrónico de usuario, clasificaciones de departamento y asignaciones de proyectos. Cuando pasa estos atributos como etiquetas de sesión, puede controlar el acceso a AWS basándose en estas etiquetas de sesión.
Para completar el [tutorial de ABAC](tutorial_attribute-based-access-control.md) pasando atributos de SAML a su sesión principal, complete las tareas de [Tutorial de IAM: definición de permisos para acceder a los recursos de AWS en función de etiquetas](tutorial_attribute-based-access-control.md), con los cambios que se incluyen en este tema.
## Requisitos previos
Para realizar los pasos necesarios para utilizar las etiquetas de sesión de SAML para ABAC, ya debe tener lo siguiente:
+ Acceso a un IdP basado en SAML donde puede crear usuarios de prueba con atributos específicos.
+ La posibilidad de iniciar sesión como usuario con permisos administrativos.
+ Experimente creando y editando usuarios, roles y políticas de IAM en la Consola de administración de AWS. Sin embargo, si necesita ayuda para recordar un proceso de administración de IAM, el tutorial de ABAC proporciona enlaces en los que puede ver las instrucciones paso a paso.
+ Experimenta la configuración de un IdP basado en SAML en IAM. Para ver más detalles y vínculos a documentación detallada de IAM, consulte [Traspaso de etiquetas de sesión mediante AssumeRoleWithSAML](id_session-tags.md#id_session-tags_adding-assume-role-saml).
## Paso 1: crear usuarios de prueba
Omita las instrucciones en [Paso 1: crear usuarios de prueba](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Dado que sus identidades están definidas en su proveedor, no es necesario que agregue usuarios de IAM para sus empleados.
## Paso 2: crear la política de ABAC
Siga las instrucciones de [Paso 2: crear la política de ABAC](tutorial_attribute-based-access-control.md#tutorial_abac_step2) para crear la política administrada especificada en IAM.
## Paso 3: crear y configurar el rol de SAML
Cuando utilice el aprendizaje de ABAC para SAML, debe realizar pasos adicionales para crear el rol, configurar el IdP de SAML y habilitar el acceso a la Consola de administración de AWS. Para obtener más información, consulte [Paso 3: crear roles](tutorial_attribute-based-access-control.md#tutorial_abac_step3).
### Paso 3A: crear el rol de SAML
Cree un único rol que confíe en el proveedor de identidades de SAML y en el usuario `test-session-tags` que creó en el paso 1. El tutorial de ABAC utiliza roles independientes con etiquetas de rol diferentes. Dado que está pasando etiquetas de sesión desde su IdP de SAML, solo necesita un rol. Para obtener información sobre cómo crear un rol basado en SAML, consulte [Creación de un rol para una federación SAML 2.0 (consola)](id_roles_create_for-idp_saml.md).
Llame al rol `access-session-tags`. Asocie una política de permisos `access-same-project-team` al rol. Edite la política de confianza del rol para utilizar la siguiente política. Para obtener instrucciones detalladas sobre cómo editar la relación de confianza de un rol, consulte [Actualizar una política de confianza de rol](id_roles_update-role-trust-policy.md).
La siguiente política de confianza del rol permite que el proveedor de identidad de SAML y el usuario `test-session-tags` asuman el rol. Cuando asumen el rol, deben pasar las tres etiquetas de sesión especificadas. La acción `sts:TagSession` es necesaria para permitir pasar etiquetas de sesión.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSamlIdentityAssumeRole",
"Effect": "Allow",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
"Condition": {
"StringLike": {
"aws:RequestTag/cost-center": "*",
"aws:RequestTag/access-project": "*",
"aws:RequestTag/access-team": [
"eng",
"qas"
]
},
"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
```
------
La instrucción `AllowSamlIdentityAssumeRole` permite a los miembros de los equipos de Ingeniería y Garantía de Calidad asumir este rol cuando se federan en AWS desde el IdP de Example Corporation. El proveedor `ExampleCorpProvider` de SAML se define en IAM. El administrador ya ha configurado la aserción de SAML para pasar las tres etiquetas de sesión requeridas. La aserción puede pasar etiquetas adicionales, pero estos tres deben estar presentes. Los atributos de la identidad pueden tener cualquier valor para las etiquetas `cost-center` y `access-project`. Sin embargo, el valor del atributo `access-team` debe coincidir con `eng` o `qas` para indicar que la identidad está en el equipo de ingeniería o control de calidad.
### Paso 3B: configurar el IdP de SAML
Configure su IdP de SAML para que pase los atributos `cost-center`, `access-project` y `access-team` como etiquetas de sesión. Para obtener más información, consulte [Traspaso de etiquetas de sesión mediante AssumeRoleWithSAML](id_session-tags.md#id_session-tags_adding-assume-role-saml).
Para pasar estos atributos como etiquetas de sesión, incluya los siguientes elementos en su aserción de SAML.
```
987654
peg
eng
```
### Paso 3C: Habilitar el acceso a la consola
Habilite el acceso a la consola para los usuarios federados de SAML. Para obtener más información, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md).
## Paso 4: Probar la creación de secretos
Federarse en la Consola de administración de AWS mediante el rol `access-session-tags`. Para obtener más información, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md). A continuación, siga las instrucciones de [Paso 4: Probar la creación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step4) para crear secretos. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC. Para obtener más información, consulte [Paso 4: Probar la creación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step4).
## Paso 5: Probar la visualización de secretos
Siga las instrucciones de [Paso 5: Probar la visualización de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step5) para ver los secretos que creó en el paso anterior. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC.
## Paso 6: Probar la escalabilidad
Siga las instrucciones de [Paso 6: Probar la escalabilidad](tutorial_attribute-based-access-control.md#tutorial_abac_step6) para probar la escalabilidad. Para ello, agregue una nueva identidad en su IdP basado en SAML con los siguientes atributos:
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`
## Paso 7: Probar la actualización y eliminación de secretos
Siga las instrucciones de [Paso 7: Probar la actualización y eliminación de secretos](tutorial_attribute-based-access-control.md#tutorial_abac_step7) para actualizar y eliminar secretos. Utilice diferentes identidades de SAML con atributos para que coincidan con las etiquetas indicadas en el tutorial de ABAC.
**importante**
Elimine todos los secretos que ha creado para evitar cargos de facturación. Para obtener más información sobre los precios de Secrets Manager, consulte [Precios de AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Resumen
Ahora ha completado correctamente todos los pasos necesarios para utilizar etiquetas de sesión y etiquetas de recursos de SAML para la administración de permisos.
**nota**
Ha agregado políticas que permiten acciones solo en determinadas condiciones. Si aplica una política diferente a los usuarios o roles que tiene permisos más amplios, es posible que las acciones no se limiten a requerir el etiquetado. Por ejemplo, si concede a un usuario permisos administrativos completos mediante la política administrada por `AdministratorAccess` AWS, estas políticas no restringen ese acceso. Para obtener más información acerca de cómo se determinan los permisos cuando se aplican varias políticas, consulte [Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
# Tutorial de IAM: permitir a los usuarios administrar sus credenciales y configuración de MFA
Puede permitir que los usuarios administren sus propias credenciales y dispositivos de autenticación multifactor (MFA) en la página **Credenciales de seguridad**. Puede utilizar la Consola de administración de AWS para configurar credenciales (claves de acceso, contraseñas, certificados de firma y claves públicas SSH) y eliminar o desactivar credenciales que no son necesarias, además de habilitar los dispositivos MFA para sus usuarios. Esto es útil para pocos usuarios; sin embargo, es una tarea que pronto podría requerir demasiado tiempo si el número de usuarios aumenta. En este tutorial se muestra cómo habilitar estas prácticas recomendadas sin que suponga una carga para los administradores.
Este tutorial muestra cómo conceder acceso a los usuarios a los servicios de AWS, pero **solo** cuando inicien sesión con MFA. Si no se han iniciado sesión con un dispositivo MFA, entonces los usuarios no pueden acceder a otros servicios.
Este flujo de trabajo incluye tres pasos básicos.
**[Paso 1: crear una política para que se cumpla el inicio de sesión de MFA](#tutorial_mfa_step1)**
Cree una política administrada por el cliente que prohíba todas las acciones ***excepto*** las pocas acciones de IAM. Estas excepciones permiten a un usuario cambiar sus propias credenciales y administrar sus dispositivos MFA en la página **Credenciales de seguridad**. Para obtener más información sobre cómo obtener acceso a esta página, consulte [Cómo cambian los usuarios de IAM su propia contraseña (consola)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**[Paso 2: asociar políticas a su grupo de usuarios de prueba](#tutorial_mfa_step2)**
Crear un grupo de usuarios cuyos miembros tengan acceso total a todas las acciones de Amazon EC2 cuando inician sesión con MFA. Para crear dicho grupo de usuarios, asocie la política administrada por AWS denominada `AmazonEC2FullAccess` y la política administrada del cliente que ha creado en el primer paso.
**[Paso 3: Probar el acceso de usuario](#tutorial_mfa_step3)**
Inicie sesión como usuario de prueba para verificar que el acceso a Amazon EC2 está bloqueado *hasta* que el usuario crea un dispositivo MFA. A continuación, el usuario puede iniciar sesión con ese dispositivo.
## Requisitos previos
Para realizar los pasos en este tutorial, deberá disponer de lo siguiente:
+ Una Cuenta de AWS en la que puede iniciar sesión como usuario de IAM con permisos administrativos.
+ Su número de ID de cuenta, que debe especificar en la política en el paso 1.
Para encontrar su número de ID de la cuenta, en la barra de navegación situada en la parte superior de la página, elija **Support (Soporte)** y, a continuación, elija **Support Center (Centro de soporte)**. Puede encontrar el ID de cuenta en el menú **Support (Soporte)** de esta página.
+ Un [dispositivo MFA virtual (basado en software)](id_credentials_mfa_enable_virtual.md), [una clave de seguridad FIDO](id_credentials_mfa_enable_fido.md) o [un dispositivo MFA basado en hardware](id_credentials_mfa_enable_physical.md).
+ Un usuario de prueba de IAM que sea miembro de un grupo de usuarios de la siguiente manera:
| Nombre de usuario | Instrucciones de nombre de usuario | Nombre del grupo de usuarios | Añadir usuario como miembro | Instrucciones para grupos de usuarios |
| --- | --- | --- | --- | --- |
| MFAUser | Elija solo la opción Habilitar acceso a la consola: opcional y asigne una contraseña. | EC2MFA | MFAUser | NO adjunte políticas o ni conceda permisos a este grupo de usuarios de ninguna otra manera. |
## Paso 1: crear una política para que se cumpla el inicio de sesión de MFA
Puede comenzar creando una política administrada por el cliente de IAM que deniegue todos los permisos, salvo los necesarios para los usuarios de IAM para que administren sus propias credenciales y dispositivos MFA.
1. Inicie sesión en Management Console de AWS como usuario con credenciales de administrador. Para cumplir con las prácticas recomendadas de IAM, no inicie sesión con las credenciales de usuario Usuario raíz de la cuenta de AWS.
**importante**
Las [prácticas recomendadas](best-practices.md) de IAM sugieren que exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder a AWS con credenciales temporales, en lugar de utilizar usuarios de IAM con credenciales a largo plazo. Para los [casos de uso específicos](gs-identities-iam-users.md) no compatibles con usuarios federados, recomendamos utilizar únicamente usuarios de IAM.
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, seleccione **Policies (Políticas)** y, a continuación, seleccione **Create policy (Crear política)**.
1. Seleccione la pestaña **JSON** y copie el texto del siguiente documento de política JSON: [AWS: permite a los usuarios de IAM autenticados por MFA administrar sus propias credenciales en la página Credenciales de seguridad](reference_policies_examples_aws_my-sec-creds-self-manage.md).
1. Pegue el texto de la política en el cuadro de texto **JSON**. Resuelva las advertencias de seguridad, errores o advertencias generales surgidos durante la validación de política y luego seleccione **Siguiente**.
**nota**
Puede alternar entre las opciones **Editor visual** y **JSON** en todo momento. Sin embargo, la política anterior, que incluye el elemento `NotAction`, no se admite en el editor visual. Para esta política, verá una notificación en la pestaña **Visual editor (Editor visual)**. Vuelva a **JSON** para seguir trabajando con esta política.
Este ejemplo de política no permite a los usuarios restablecer una contraseña al iniciar sesión en la Consola de administración de AWS por primera vez. Recomendamos que no conceda permisos a los nuevos usuarios hasta después de que inicien sesión y restablezcan su contraseña.
1. En la página **Revisar y crear**, escriba **Force\$1MFA** como nombre de la política. Para la descripción de la política, escriba **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.**. En el área **Etiquetas**, puede agregar opcionalmente pares clave-valor de etiquetas a la política administrada por el cliente. Revise los permisos concedidos por la política y, a continuación, seleccione **Crear política** para guardar su trabajo.
La nueva política aparece en la lista de las políticas administradas y está lista para asociar.
## Paso 2: asociar políticas a su grupo de usuarios de prueba
A continuación, se conectan dos políticas al grupo de usuarios de IAM de prueba, que se utilizarán para conceder los permisos protegidos por MFA.
1. En el panel de navegación, elija **User groups** (Grupos de usuarios).
1. En el cuadro de búsqueda, escriba **`EC2MFA`** y, a continuación, elija el nombre del grupo en la lista (no la casilla de verificación).
1. Elija la pestaña **Permisos**, elija **Agregar permisos** y luego, **Asociar políticas**.
1. En la página **Attach permission policies to EC2MFA group** (Adjuntar políticas de permisos al grupo EC2MFA), en el campo de búsqueda, escriba **EC2Full**. Luego, seleccione la casilla de verificación situada junto a **AmazonEC2FullAccess** en la lista. No guarde aún los cambios.
1. En el cuadro de búsqueda, escriba **Force** y, a continuación, seleccione la casilla de verificación junto a **Force\$1MFA** en la lista.
1. Seleccione **Asociar políticas**.
## Paso 3: Probar el acceso de usuario
En esta parte del tutorial, inicie sesión como usuario de prueba y verifique que la política funciona según lo previsto.
1. Inicie sesión en su Cuenta de AWS como **MFAUser** con la contraseña que haya asignado en la sección anterior. Use la URL: `https://.signin.aws.amazon.com/console`
1. Elija **EC2** para abrir la consola de Amazon EC2 y comprobar que el usuario no tiene permisos para realizar ninguna actividad.
1. En la esquina superior derecha de la barra de navegación, elija el nombre de usuario `MFAUser` y, a continuación, **My Security Credentials** (Mis credenciales de seguridad).
![\[Enlace de credenciales de seguridad de la consola de administración de AWS\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)
1. Ahora agregue un dispositivo MFA. En la sección **Multi-Factor Authentication (MFA)**, elija **Assign MFA device (Asignar dispositivo MFA)**.
**nota**
Es posible que reciba un error que indica que no está autorizado a realizar `iam:DeleteVirtualMFADevice`. Esto podría ocurrir si alguien anteriormente comenzó la asignación de un dispositivo MFA virtual este usuario y canceló el proceso. Para continuar, usted u otro administrador debe eliminar el dispositivo MFA virtual existente sin asignar del usuario. Para obtener más información, consulte [No tengo autorización para realizar la operación iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).
1. En este tutorial, utilizamos un dispositivo MFA virtual (basado en software), como la aplicación Google Authenticator en un teléfono móvil. Elija **Authenticator app** (Aplicación del autenticador) y, a continuación, haga clic en **Next** (Siguiente).
IAM generará y mostrará la información de configuración del dispositivo MFA virtual, incluido un gráfico de código QR. El gráfico es una representación de la clave de configuración secreta que se puede introducir manualmente en dispositivos que no admiten códigos QR.
1. Abra su aplicación de MFA virtual. (Para ver una lista de las aplicaciones que puede utilizar para alojar dispositivos MFA virtuales, consulte [Aplicaciones MFA virtuales)](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications). Si la aplicación de MFA virtual admite varias cuentas (varios dispositivos de MFA virtuales), elija la opción para crear una nueva cuenta (un nuevo dispositivo MFA virtual).
1. Determine si la aplicación MFA admite códigos QR y, a continuación, lleve a cabo alguna de las siguientes operaciones:
+ Desde el asistente, seleccione **Show QR code (Mostrar código QR)**. A continuación, utilice la aplicación para analizar el código QR. Por ejemplo, puede elegir el icono de la cámara o una opción similar a **Scan code (Escanear código)** y, a continuación, utilizar la cámara del dispositivo para escanear el código.
+ En el asistente **Set up device** (Configurar el dispositivo), elija **Show secret key** (Mostrar clave secreta) y, a continuación, escriba la clave secreta en su aplicación MFA.
Cuando haya terminado, el dispositivo MFA virtual comenzará a generar contraseñas de uso único.
1. En el asistente **Set up device** (Configurar el dispositivo), en el cuadro **Enter the code from your authenticator app** (Introducir el código de la aplicación de autenticación), escriba la contraseña de uso único que aparece actualmente en el dispositivo MFA virtual. Elija **Register MFA** (Registrar MFA).
**importante**
Envíe su solicitud inmediatamente después de generar el código. Si genera los códigos y después espera demasiado tiempo a enviar la solicitud, el dispositivo MFA está correctamente asociado al usuario. Sin embargo, el dispositivo MFA no está sincronizado. Esto ocurre porque las contraseñas temporales de un solo uso (TOTP) caducan tras un corto periodo de tiempo. Si esto ocurre, puede [volver a sincronizar el dispositivo](id_credentials_mfa_sync.md).
El dispositivo MFA virtual ya está listo para utilizarlo con AWS.
1. Cierre la sesión de la consola y, a continuación, vuelva a iniciar sesión en **MFAUser**. En esta ocasión AWS le solicita un código de MFA desde su teléfono. Al hacerlo, escriba el código en la casilla y, a continuación, seleccione **Submit (Enviar)**.
1. Elija **EC2** para abrir de nuevo la consola de Amazon EC2. Observe que esta vez puede ver toda la información y realizar cualquier acción que desee. Si va a cualquier otra consola como este usuario, verá mensajes de acceso denegado. El motivo es que las políticas de este tutorial conceden acceso únicamente a Amazon EC2.
## Recursos relacionados
Para obtener más información, consulte los siguientes temas:
+ [Autenticación multifactor de AWS en IAM](id_credentials_mfa.md)
+ [Inicio de sesión con MFA habilitado](console_sign-in-mfa.md)
# Tutorial de IAM: use una plantilla de CloudFormation para crear un proveedor de identidades (IdP) de SAML
Para configurar la federación de SAML en su cuenta de AWS, debe crear un proveedor de identidades (IdP) de SAML. En este tutorial, se muestra cómo usar una plantilla de CloudFormation para crear un IdP de SAML que establezca confianza entre AWS y su IdP externo.
La plantilla crea un IdP de SAML configurado con el documento de metadatos de su IdP. A continuación, los roles de IAM federados pueden hacer referencia a este IdP para permitir que los usuarios autenticados de su IdP externo accedan a los recursos de AWS.
El recurso desplegado consiste en un IdP de SAML configurado con el documento de metadatos de su IdP y la configuración de cifrado opcional.
## Requisitos previos
En este tutorial se presupone que los elementos siguientes ya existen:
+ Python 3.6 o una versión posterior instalada en su máquina local para ejecutar el comando de Python utilizado en este tutorial a fin de formatear el archivo XML de metadatos SAML de su IdP.
+ Un documento de metadatos de SAML de su IdP externo guardado como un archivo XML.
## Crear un IdP de SAML mediante CloudFormation
Para crear el IdP de SAML, debe crear una plantilla de CloudFormation y utilizarla para crear una pila que contenga el recurso del IdP.
### Crear la plantilla
Primero, cree la plantilla de CloudFormation.
1. En la sección [Plantilla](#tutorial_saml-idp-template), haga clic en el icono de copia de la pestaña **JSON** o **YAML** para copiar el contenido de la plantilla.
1. Pegue el contenido de la plantilla en un archivo nuevo.
1. Guarde el archivo localmente.
### Creación de la pila
A continuación, utilice la plantilla que creó para aprovisionar una pila de CloudFormation.
1. Abra la consola de CloudFormation en [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. En la página **Pilas**, para **Crear pila** elija **Con nuevos recursos (estándar)**.
1. En Especificar plantilla:
1. En **Requisito previo**, elija **Seleccionar una plantilla existente**.
1. En **Especificar plantilla**, elija **Cargar un archivo de plantilla**.
1. Seleccione **Elegir archivo** para navegar hasta el archivo y seleccionarlo.
1. Elija **Siguiente**.
1. Especifique los siguientes detalles de la pila:
1. Introduzca un nombre de pila.
1. En el caso de **IdentityProviderName**, puede dejar este campo vacío para generar automáticamente un nombre basado en el nombre de la pila o introducir un nombre personalizado para su IdP de SAML. Los nombres personalizados deben contener únicamente caracteres alfanuméricos, puntos y guiones.
1. En el caso de **IdentityProviderSAMLMetadataDocument**, debe formatear el archivo XML de metadatos de SAML en una sola línea antes de pegarlo en este campo. Esto es necesario porque la consola de CloudFormation requiere que el contenido XML se formatee como una sola línea cuando se pasa por los parámetros de la consola.
Use el siguiente comando de Python para cambiar el formato del archivo XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**nota**
El documento de metadatos de SAML del IdP debe estar formateado en una sola línea para introducir los parámetros en la consola. El comando Python elimina los saltos de línea y los espacios en blanco adicionales para crear el formato requerido y, al mismo tiempo, mantener todo el contenido y la estructura originales.
Copie el resultado del comando Python y péguelo en el campo **IdentityProviderSAMLMetadataDocument**.
Ejemplo de documento de metadatos de SAML formateado (abreviado):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Para otros parámetros, acepte los valores predeterminados o introduzca los propios en función de sus requisitos:
+ **IdentityProviderAddPrivateKey**: clave privada opcional para descifrar las aserciones de SAML
+ **IdentityProviderAssertionEncryptionMode**: opcional, establece el modo de cifrado para las aserciones de SAML (permitido, obligatorio o vacío)
1. Elija **Siguiente**.
1. Configure las opciones la pila:
1. En las **opciones de error de pila**, seleccione **Eliminar todos los recursos recién creados.**
**nota**
Si elige esta opción, evita que se le facturen los recursos cuya política de eliminación especifique que se conservarán incluso si se produce un error durante la creación de la pila.
1. Acepte todos los demás valores predeterminados.
1. En **Capacidades**, seleccione la casilla para aceptar que CloudFormation puede crear recursos de IAM en su cuenta.
1. Elija **Siguiente**.
1. Revise los detalles de la pila y elija **Enviar**.
CloudFormation crea el stack. Una vez completada la creación de la pila, los recursos de la pila están listos para usarse. Puede usar la pestaña **Recursos** de la página de detalles de la pila para ver los recursos que se aprovisionaron en su cuenta.
La pila generará los siguientes valores, que puede ver en la pestaña **Resultados**:
+ **ProviderARN**: el ARN del IdP de SAML creado (por ejemplo, `arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Necesitará este ARN para crear funciones que confíen en este proveedor.
+ **ProviderName**: el nombre del IdP de SAML creado (por ejemplo, `CompanyIdP` si especificó un nombre personalizado o `my-saml-stack-saml-provider` si utilizó el nombre predeterminado).
Estos resultados también se exportan, lo que permite que otras pilas de CloudFormationlas importen mediante la función de `Fn::ImportValue`.
## Verificar el IdP de SAML
Una vez creado el IdP de SAML, puede verificar su configuración y anotar su ARN para usarlo con los roles federados.
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, elija **Proveedores de identidades**.
Ahora debería poder ver el IdP de SAML recién creado en la lista.
1. Seleccione el nombre del IdP para ver sus detalles.
En la página de detalles del IdP, puede ver el documento de metadatos de SAML y otros detalles de configuración.
1. Anote el **ARN del proveedor** que aparece en la página de detalles.
Necesitará este ARN al crear roles de IAM federados que confíen en este IdP.
1. Revise el documento de metadatos para asegurarse de que coincida con lo que proporcionó su IdP externo.
El IdP de SAML ya está listo para usarse en roles de IAM federados. Puede crear roles que confíen en este IdP para permitir que los usuarios autenticados de su IdP externo asuman esos roles y accedan a los recursos de AWS.
## Limpieza: elimine recursos
Como último paso, eliminará la pila y los recursos que contiene.
1. Abra la consola de CloudFormation.
1. En la página **Pilas**, seleccione la pila creada a partir de la plantilla, seleccione **Eliminar** y, a continuación, confirme **Eliminar**.
CloudFormation inicia la eliminación de la pila y de todos los recursos que incluye.
## Detalles de la plantilla de CloudFormation
### Recursos
La plantilla de CloudFormation para este tutorial crea el siguiente recurso en su cuenta:
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP de SAML que establece confianza entre AWS y su IdP externo.
### Configuración
La plantilla incluye los siguientes parámetros configurables:
+ **IdentityProviderName**: el nombre del IdP de SAML (déjelo en blanco para que el nombre se genere automáticamente)
Ejemplo: `CompanyIdP` o `EnterpriseSSO`
+ **IdentityProviderSAMLMetadataDocument**: el documento de metadatos de SAML de su IdP externo (formateado en una sola línea)
+ **IdentityProviderAddPrivateKey**: clave privada opcional para descifrar las aserciones de SAML
+ **IdentityProviderAssertionEncryptionMode**: opcional, establece el modo de cifrado para las aserciones de SAML
## Plantilla de CloudFormation
Guarde el siguiente código JSON o YAML como un archivo independiente para usarlo como plantilla de CloudFormation en este tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
}
},
"Conditions": {
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]},
"HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"Tags": [
{
"Key": "Name",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}
}
],
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
}
},
"Outputs": {
"ProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"}
}
},
"ProviderName": {
"Description": "Name of the SAML Identity Provider",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens'
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
Conditions:
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]]
Resources:
SAMLProvider:
Type: 'AWS::IAM::SAMLProvider'
Properties:
Name: !If
- HasCustomName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
Tags:
- Key: Name
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
Outputs:
ProviderARN:
Description: 'ARN of the created SAML Identity Provider'
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-ProviderARN'
ProviderName:
Description: 'Name of the SAML Identity Provider'
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
Export:
Name: !Sub '${AWS::StackName}-ProviderName'
```
------
# Tutorial de IAM: use una plantilla de CloudFormation para crear un rol de IAM federado de SAML
Si tiene un proveedor de identidades (IdP) de SAML existente configurado en su cuenta de AWS, puede crear funciones de IAM federadas que confíen en ese IdP. En este tutorial, se muestra cómo usar una plantilla de CloudFormation para crear un rol de IAM federado de SAML que puedan asumir los usuarios autenticados a través de su IdP externo.
La plantilla crea un rol de IAM federado con una política de confianza que permite que el IdP de SAML asuma el rol. Los usuarios autenticados por su IdP externo pueden asumir este rol para acceder a los recursos de AWS en función de los permisos que están adjuntos al rol.
El recurso desplegado consta de los siguientes elementos:
+ Un rol de IAM federado que confía en su IdP de SAML existente.
+ Políticas administradas configurables que se pueden adjuntar al rol para conceder permisos específicos.
+ Configuraciones opcionales de límite de permisos y duración de las sesiones.
## Requisitos previos
En este tutorial se presupone que los elementos siguientes ya existen:
+ Un IdP de SAML existente configurado en su cuenta de AWS. Si no lo tiene, puede crear uno con el tutorial de [Tutorial de IAM: use una plantilla de CloudFormation para crear un proveedor de identidades (IdP) de SAML](tutorial_saml-idp.md).
+ El ARN de su IdP de SAML, que deberá especificar como parámetro durante la creación de la pila.
+ Python 3.6 o una versión posterior instalada en su máquina local para ejecutar el comando de Python utilizado en este tutorial a fin de formatear el archivo XML de metadatos SAML de su IdP.
## Crear un rol federado de SAML con CloudFormation
Para crear el rol federado de SAML, debe crear una plantilla de CloudFormation y utilizarla para crear una pila que contenga el rol.
### Crear la plantilla
Primero, cree la plantilla de CloudFormation.
1. En la sección [Plantilla](#tutorial_saml-federated-role-template), haga clic en el icono de copia de la pestaña **JSON** o **YAML** para copiar el contenido de la plantilla.
1. Pegue el contenido de la plantilla en un archivo nuevo.
1. Guarde el archivo localmente.
### Creación de la pila
A continuación, utilice la plantilla que creó para aprovisionar una pila de CloudFormation.
1. Abra la consola de CloudFormation en [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. En la página **Pilas**, para **Crear pila** elija **Con nuevos recursos (estándar)**.
1. En Especificar plantilla:
1. En **Requisito previo**, elija **Seleccionar una plantilla existente**.
1. En **Especificar plantilla**, elija **Cargar un archivo de plantilla**.
1. Seleccione **Elegir archivo** para navegar hasta el archivo y seleccionarlo.
1. Elija **Siguiente**.
1. Especifique los siguientes detalles de la pila:
1. Introduzca un nombre de pila.
1. Para **SAMLProviderARN**, introduzca el ARN de su IdP de SAML existente. Debe estar en el formato `arn:aws:iam::123456789012:saml-provider/YourProviderName`.
Ejemplo:: `arn:aws:iam::123456789012:saml-provider/CompanyIdP`
**nota**
Si creó su IdP de SAML con el tutorial de [Tutorial de IAM: use una plantilla de CloudFormation para crear un proveedor de identidades (IdP) de SAML](tutorial_saml-idp.md), puede encontrar el ARN del proveedor en la pestaña de resultados de esa pila de CloudFormation.
1. Para **RoleName**, puede dejar este campo vacío para generar automáticamente un nombre basado en el nombre de la pila o introducir un nombre personalizado para el rol de IAM.
Ejemplo: `SAML-Developer-Access` o `SAML-ReadOnly-Role`
1. Para otros parámetros, acepte los valores predeterminados o introduzca los propios en función de sus requisitos:
+ **RoleSessionDuration**: duración máxima de la sesión en segundos (3600-43 200, el valor predeterminado es 7200)
Ejemplo: `14400` (4 horas)
+ **RolePermissionsBoundary**: ARN opcional de una política de límite de permisos
Ejemplo:: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**: ruta para el rol de IAM (el valor predeterminado es /)
Ejemplo:: `/saml-roles/`
+ **ManagedPolicy1-5**: se pueden adjuntar ARN opcionales de hasta 5 políticas administradas
Ejemplo de ManagedPolicy1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Ejemplo de ManagedPolicy2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Elija **Siguiente**.
1. Configure las opciones la pila:
1. En las **opciones de error de pila**, seleccione **Eliminar todos los recursos recién creados.**
**nota**
Si elige esta opción, evita que se le facturen los recursos cuya política de eliminación especifique que se conservarán incluso si se produce un error durante la creación de la pila.
1. Acepte todos los demás valores predeterminados.
1. En **Capacidades**, seleccione la casilla para aceptar que CloudFormation puede crear recursos de IAM en su cuenta.
1. Elija **Siguiente**.
1. Revise los detalles de la pila y elija **Enviar**.
CloudFormation crea el stack. Una vez completada la creación de la pila, los recursos de la pila están listos para usarse. Puede usar la pestaña **Recursos** de la página de detalles de la pila para ver los recursos que se aprovisionaron en su cuenta.
La pila generará el siguiente valor, que puede ver en la pestaña **Resultados**:
+ **RoleARN**: el ARN del rol de IAM creado (por ejemplo, `arn:aws:iam::123456789012:role/SAML-Developer-Access` o `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` si se utiliza un nombre generado automáticamente).
Necesitará este ARN del rol al configurar su IDP para enviar los atributos de SAML adecuados para la asunción del rol.
## Probar el rol federado de SAML
Una vez que se haya creado el rol federado de SAML, puede verificar su configuración y probar la configuración de la federación.
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación.
1. Busque y seleccione el rol federado que acaba de crear.
Si proporcionó un nombre de rol personalizado, búsquelo. Si dejó el parámetro RoleName vacío, el rol tendrá un nombre generado automáticamente que se basa en el nombre de la pila y un identificador único.
1. Seleccione la pestaña **Relaciones de confianza** para revisar la política de confianza.
La política de confianza debe mostrar que se confía en su IdP de SAML para asumir este rol con la condición de que la audiencia de SAML (`SAML:aud`) coincida con `https://signin.aws.amazon.com/saml`.
1. Seleccione la pestaña **Permisos** para revisar las políticas asociadas.
Puede ver todas las políticas administradas que se adjuntaron al rol durante su creación.
1. Anote el **ARN de rol** que se muestra en la página de resumen del rol.
Necesitará este ARN para configurar su IdP externo y permitir que los usuarios asuman este rol.
El rol federado de SAML ya está listo para usarse. Configure su IdP externo para incluir el ARN de este rol en las aserciones de SAML, y los usuarios autenticados podrán asumir este rol para acceder a los recursos de AWS.
## Limpieza: elimine recursos
Como último paso, eliminará la pila y los recursos que contiene.
1. Abra la consola de CloudFormation.
1. En la página **Pilas**, seleccione la pila creada a partir de la plantilla, seleccione **Eliminar** y, a continuación, confirme **Eliminar**.
CloudFormation inicia la eliminación de la pila y de todos los recursos que incluye.
## Detalles de la plantilla de CloudFormation
### Recursos
La plantilla de CloudFormation para este tutorial crea el siguiente recurso en su cuenta:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): un rol de IAM federado que pueden asumir los usuarios autenticados a través del IdP de SAML.
### Configuración
La plantilla incluye los siguientes parámetros configurables:
+ **RoleName**: nombre del rol de IAM (déjelo en blanco para que el nombre se genere automáticamente)
+ **SAMLProviderARN**: ARN del IdP de SAML (obligatorio)
+ **RoleSessionDuration**: duración máxima de la sesión en segundos (3600-43 200, el valor predeterminado es 7200)
+ **RolePermissionsBoundary**: ARN opcional de una política de límite de permisos
+ **RolePath**: ruta para el rol de IAM (el valor predeterminado es /)
+ **ManagedPolicy1-5**: se pueden adjuntar ARN opcionales de hasta 5 políticas administradas
## Plantilla de CloudFormation
Guarde el siguiente código JSON o YAML como un archivo independiente para usarlo como plantilla de CloudFormation en este tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-federated-role",
"Parameters": {
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"SAMLProviderARN": {
"Type": "String",
"Description": "ARN of the SAML Identity Provider",
"AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be a valid SAML provider ARN"
},
"RoleSessionDuration": {
"Type": "Number",
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM role (must start and end with /)",
"Default": "/",
"AllowedPattern": "^\/.*\/$|^\/$",
"ConstraintDescription": "Role path must start and end with forward slash (/)"
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}
},
"Resources": {
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Description": "IAM role with SAML provider trust",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProviderARN"}
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-federated-role'
Parameters:
RoleName:
Type: String
Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')'
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-'
SAMLProviderARN:
Type: String
Description: 'ARN of the SAML Identity Provider'
AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be a valid SAML provider ARN'
RoleSessionDuration:
Type: Number
Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)'
MinValue: 3600
MaxValue: 43200
Default: 7200
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RolePath:
Type: String
Description: 'Path for the IAM role (must start and end with /)'
Default: "/"
AllowedPattern: '^\/.*\/$|^\/$'
ConstraintDescription: 'Role path must start and end with forward slash (/)'
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
Resources:
SAMLFederatedRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Description: 'IAM role with SAML provider trust'
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
Path: !Ref RolePath
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProviderARN
Action: 'sts:AssumeRoleWithSAML'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns:
!Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue']
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue']
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue']
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue']
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue']
Outputs:
RoleARN:
Description: 'ARN of the created IAM Role'
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
```
------
# Tutorial de IAM: use una plantilla de CloudFormation para crear un proveedor de identidades (IdP) de SAML y un rol de IAM federado de SAML
Para familiarizarse con la federación de SAML y sus capacidades, utilizará una plantilla de CloudFormation para configurar un proveedor de identidades (IdP) y el rol de IAM federado de SAML asociado. En este tutorial, se muestra cómo crear ambos recursos en una sola pila.
La plantilla crea un IdP de SAML que se puede utilizar para el acceso federado a los recursos de AWS, junto con un rol de IAM que confía en el proveedor de SAML. Los usuarios autenticados por su IdP externo pueden asumir este rol para acceder a los recursos de AWS.
Los recursos desplegados constan de los siguientes elementos:
+ Un IdP de SAML configurado con el documento de metadatos de su IdP.
+ Un rol de IAM federado que confía en el IdP de SAML y que pueden asumir los usuarios autenticados.
+ Políticas administradas configurables que se pueden adjuntar al rol para conceder permisos específicos.
## Requisitos previos
En este tutorial se presupone que los elementos siguientes ya existen:
+ Python 3.6 o una versión posterior instalada en su máquina local para ejecutar el comando de Python utilizado en este tutorial a fin de formatear el archivo XML de metadatos SAML de su IdP.
+ Un documento de metadatos de SAML de su IdP externo guardado como un archivo XML.
## Crear un IdP y un rol de SAML mediante CloudFormation
Para crear el IdP y el rol federado de SAML, debe crear una plantilla de CloudFormation y utilizarla para crear una pila que contenga ambos recursos.
### Crear la plantilla
Primero, cree la plantilla de CloudFormation.
1. En la sección [Plantilla](#tutorial_saml-idp-and-federated-role-template), haga clic en el icono de copia de la pestaña **JSON** o **YAML** para copiar el contenido de la plantilla.
1. Pegue el contenido de la plantilla en un archivo nuevo.
1. Guarde el archivo localmente.
### Creación de la pila
A continuación, utilice la plantilla que creó para aprovisionar una pila de CloudFormation.
1. Abra la consola de CloudFormation en [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. En la página **Pilas**, para **Crear pila** elija **Con nuevos recursos (estándar)**.
1. En Especificar plantilla:
1. En **Requisito previo**, elija **Seleccionar una plantilla existente**.
1. En **Especificar plantilla**, elija **Cargar un archivo de plantilla**.
1. Seleccione **Elegir archivo** para navegar hasta el archivo y seleccionarlo.
1. Elija **Siguiente**.
1. Especifique los siguientes detalles de la pila:
1. Introduzca un nombre de pila.
1. En el caso de **IdentityProviderName**, puede dejar este campo vacío para generar automáticamente un nombre basado en el nombre de la pila o introducir un nombre personalizado para su IdP de SAML.
Ejemplo: `CompanyIdP` o `EnterpriseSSO`
1. En el caso de **IdentityProviderSAMLMetadataDocument**, debe formatear el archivo XML de metadatos de SAML en una sola línea antes de pegarlo en este campo. Esto es necesario porque la consola de CloudFormation requiere que el contenido XML se formatee como una sola línea cuando se pasa por los parámetros de la consola.
Use el siguiente comando de Python para cambiar el formato del archivo XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**nota**
El documento de metadatos de SAML del IdP debe estar formateado en una sola línea para introducir los parámetros en la consola. El comando Python elimina los saltos de línea y los espacios en blanco adicionales para crear el formato requerido y, al mismo tiempo, mantener todo el contenido y la estructura originales.
Copie el resultado del comando Python y péguelo en el campo **IdentityProviderSAMLMetadataDocument**.
Ejemplo de documento de metadatos de SAML formateado (abreviado):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Para **RoleName**, puede dejar este campo vacío para generar automáticamente un nombre basado en el nombre de la pila o introducir un nombre personalizado para el rol de IAM federado.
Ejemplo: `SAML-Developer-Access` o `SAML-ReadOnly-Role`
1. Para otros parámetros, acepte los valores predeterminados o introduzca los propios en función de sus requisitos:
+ **IdentityProviderAddPrivateKey**: clave privada opcional para descifrar las aserciones de SAML
+ **IdentityProviderAssertionEncryptionMode**: modo de cifrado para las aserciones de SAML
Valores de ejemplo: `Allowed`, `Required`, o déjelos en blanco si no se cifra
+ **RoleSessionDuration**: duración máxima de la sesión en segundos (3600-43 200, el valor predeterminado es 7200)
Ejemplo: `14400` (4 horas)
+ **RolePermissionsBoundary**: ARN opcional de una política de límite de permisos
Ejemplo:: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**: ruta para el rol de IAM (el valor predeterminado es /)
Ejemplo:: `/saml-roles/`
+ **RoleManagedPolicy1-5**: se pueden adjuntar ARN opcionales de hasta 5 políticas administradas
Ejemplo de RoleManagedPolicy1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Ejemplo de RoleManagedPolicy2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Elija **Siguiente**.
1. Configure las opciones la pila:
1. En las **opciones de error de pila**, seleccione **Eliminar todos los recursos recién creados.**
**nota**
Si elige esta opción, evita que se le facturen los recursos cuya política de eliminación especifique que se conservarán incluso si se produce un error durante la creación de la pila.
1. Acepte todos los demás valores predeterminados.
1. En **Capacidades**, seleccione la casilla para aceptar que CloudFormation puede crear recursos de IAM en su cuenta.
1. Elija **Siguiente**.
1. Revise los detalles de la pila y elija **Enviar**.
CloudFormation crea el stack. Una vez completada la creación de la pila, los recursos de la pila están listos para usarse. Puede usar la pestaña **Recursos** de la página de detalles de la pila para ver los recursos que se aprovisionaron en su cuenta.
La pila generará los siguientes valores, que puede ver en la pestaña **Resultados**:
+ **RoleARN**: el ARN del rol de IAM creado (por ejemplo, `arn:aws:iam::123456789012:role/SAML-Developer-Access` o `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` si se utiliza un nombre generado automáticamente).
+ **IdentityProviderARN**: el ARN del IDP de SAML creado (por ejemplo, `arn:aws:iam::123456789012:saml-provider/CompanyIdP` ).
Necesitará estos dos ARN al configurar su IDP para enviar los atributos de SAML adecuados para la asunción del rol.
## Probar la federación de SAML
Una vez que se hayan creado el IdP y el rol federado de SAML, puede probar la configuración de la federación.
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, elija **Proveedores de identidades**.
Ahora debería poder ver el IdP de SAML recién creado en la lista.
1. Seleccione el nombre del IdP para ver sus detalles.
En la página de detalles del IdP, puede ver el documento de metadatos de SAML y otros detalles de configuración.
1. Seleccione **Roles** en el panel de navegación.
1. Busque y seleccione el rol federado que acaba de crear.
En la página de detalles del rol, puede ver la política de confianza que permite que el IdP de SAML asuma este rol.
1. Seleccione la pestaña **Relaciones de confianza** para revisar la política de confianza.
La política de confianza debe mostrar que se confía en el IdP de SAML para asumir este rol con la condición de que la audiencia de SAML (`SAML:aud`) coincida con `https://signin.aws.amazon.com/saml`.
## Limpieza: elimine recursos
Como último paso, eliminará la pila y los recursos que contiene.
1. Abra la consola de CloudFormation.
1. En la página **Pilas**, seleccione la pila creada a partir de la plantilla, seleccione **Eliminar** y, a continuación, confirme **Eliminar**.
CloudFormation inicia la eliminación de la pila y de todos los recursos que incluye.
## Detalles de la plantilla de CloudFormation
### Recursos
La plantilla de CloudFormation para este tutorial crea los siguientes recursos en su cuenta:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP de SAML que establece confianza entre AWS y su IdP externo.
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): un rol de IAM federado que pueden asumir los usuarios autenticados a través del IdP de SAML.
### Configuración
La plantilla incluye los siguientes parámetros configurables:
+ **IdentityProviderName:** nombre del IdP de SAML (déjelo en blanco para que el nombre se genere automáticamente)
+ **IdentityProviderSAMLMetadataDocument**: documento de metadatos de SAML de su IdP (obligatorio)
+ **IdentityProviderAddPrivateKey**: clave privada opcional para descifrar las aserciones de SAML
+ **IdentityProviderAssertionEncryptionMode**: modo de cifrado para las aserciones de SAML
+ **RoleName**: nombre del rol de IAM (déjelo en blanco para que el nombre se genere automáticamente)
+ **RolePath**: ruta para el rol de IAM (el valor predeterminado es /)
+ **RolePermissionsBoundary**: ARN opcional de una política de límite de permisos
+ **RoleSessionDuration**: duración máxima de la sesión en segundos (3600-43 200, el valor predeterminado es 7200)
+ **RoleManagedPolicy1-5**: se pueden adjuntar ARN opcionales de hasta 5 políticas administradas
## Plantilla de CloudFormation
Guarde el siguiente código JSON o YAML como un archivo independiente para usarlo como plantilla de CloudFormation en este tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
},
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM Role",
"AllowedPattern": "(^\\/$)|(^\\/.*\\/$)",
"Default": "/"
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RoleSessionDuration": {
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"Type": "Number",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]},
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]},
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
},
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"Description": "SAML federated IAM role for SSO access with specified permissions",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProvider"}
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
},
"IdentityProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
RoleName:
Type: String
Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
RolePath:
Type: String
Description: Path for the IAM Role
AllowedPattern: (^\/$)|(^\/.*\/$)
Default: "/"
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RoleSessionDuration:
Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)
Type: Number
MinValue: 3600
MaxValue: 43200
Default: 7200
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]]
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
Resources:
SAMLProvider:
Type: AWS::IAM::SAMLProvider
Properties:
Name: !If
- HasCustomProviderName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasAssertionEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
SAMLFederatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Path: !Ref RolePath
Description: "SAML federated IAM role for SSO access with specified permissions"
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProvider
Action:
- 'sts:AssumeRole'
- 'sts:SetSourceIdentity'
- 'sts:TagSession'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns: !Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"]
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"]
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"]
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"]
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"]
Outputs:
RoleARN:
Description: ARN of the created IAM Role
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
IdentityProviderARN:
Description: ARN of the created SAML Identity Provider
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-IdentityProviderARN'
```
------