# 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.