AWS Identity and Access Management
Guía del usuario

Tutorial: Delegación del acceso entre cuentas de AWS mediante roles de IAM

En este tutorial se enseña a utilizar un rol para delegar el acceso a recursos que se encuentran en cuentas de AWS diferentes y que son de su propiedad (Producción y Desarrollo). Los recursos de una cuenta los comparte con usuarios de otra cuenta. Al configurar de esta forma un acceso entre cuentas, no necesitará 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 la otra para obtener acceso a los recursos que se encuentran 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, se parte de la base de que en la cuenta Producción se administran las aplicaciones en funcionamiento, mientras que la cuenta Desarrollo es un entorno de pruebas donde los desarrolladores y los evaluadores prueban las aplicaciones libremente. 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 Desarrollo, donde tiene dos grupos de IAM: Desarrolladores y Evaluadores. En ambos grupos, los usuarios tienen permiso para trabajar en la cuenta Desarrollo y obtener acceso a los recursos de esta. De vez en cuando, un desarrollador debe actualizar las aplicaciones en funcionamiento de la cuenta Producción. Dichas aplicaciones están almacenadas en un bucket de Amazon S3 denominado productionapp.

Al acabar este tutorial, tendrá un rol en la cuenta Producción (la cuenta que confía) que permitirá a los usuarios de la cuenta Desarrollo (la cuenta de confianza) obtener acceso al bucket productionapp de la cuenta Producción. Los desarrolladores pueden utilizar el rol en la Consola de administración de AWS para obtener acceso al bucket productionapp de la cuenta Producción. También pueden obtener acceso al bucket mediante llamadas a la API que se autentican con credenciales temporales que el rol proporciona. Si un evaluador realiza intentos similares, obtendrá un error.

Este flujo de trabajo incluye tres pasos básicos.

Paso 1: Crear un rol

En primer lugar, la Consola de administración de AWS se utiliza para establecer una relación de confianza entre la cuenta Producción (número de ID 999999999999) y la cuenta Desarrollo (número de ID 111111111111). Comience creando un rol de IAM llamado UpdateApp. Cuando cree el rol, defina la cuenta Desarrollo como una entidad de confianza y especifique una política de permisos que permita a los usuarios de confianza actualizar el bucket productionapp.

Paso 2: Conceder acceso al rol

En este paso del tutorial, debe modificar la política de grupo de IAM para que se rechace el acceso de los evaluadores al rol UpdateApp. Como en este caso los evaluadores tienen acceso de usuario avanzado, debemos denegar explícitamente la posibilidad de utilizar el rol.

Paso 3: Probar el acceso alternando roles

Por último, como desarrollador, utilice el rol UpdateApp para actualizar el bucket productionapp en la cuenta Producción. Puede ver cómo obtener acceso al rol mediante la consola de AWS, la AWS CLI y la API.

Requisitos previos

En este tutorial se presupone que los elementos siguientes ya existen:

  • Dos cuentas de AWS independientes que puedan utilizarse: una para representar la cuenta Desarrollo y la otra para representar la cuenta Producción.

  • Los usuarios y grupos de la cuenta Desarrollo creados y configurados como se indica a continuación:

    Usuario Grupo Permisos
    David Desarrolladores Ambos usuarios pueden iniciar sesión y utilizar la Consola de administración de AWS en la cuenta Development.
    Theresa Evaluadores
  • No necesita tener usuarios o grupos creados en la cuenta Producción.

  • Un bucket de Amazon S3 creado en la cuenta Producción. En este tutorial lo denominamos ProductionApp, pero debido a que los nombres de bucket de S3 deben ser únicos globalmente, deberá utilizar un bucket con otro nombre.

Paso 1: Crear un rol

Para permitir a usuarios de una cuenta de AWS obtener acceso a los recursos de otra cuenta de AWS, cree un rol que establezca quién puede obtener acceso a dicha cuenta y qué permisos concede a los usuarios que cambian a ella.

En este paso del tutorial, creará el rol en la cuenta Producción y especificará la cuenta Desarrollo como entidad de confianza. También limitará los permisos del rol a un acceso de solo lectura y escritura al bucket productionapp. Todos los que tengan permiso para utilizar el rol podrán leer y escribir en el bucket productionapp.

Para poder crear un rol, necesitará el ID de la cuenta AWS Desarrollo. El ID de cuenta es un identificador exclusivo que se asigna a cada cuenta de AWS.

Para obtener el ID de cuenta de AWS Desarrollo

  1. Inicie sesión en la Consola de administración de AWS como administrador de la cuenta Desarrollo y abra la consola de IAM en https://console.aws.amazon.com/iam/.

  2. En la barra de navegación, elija Support (Soporte) y, a continuación, Support Center (Centro de soporte). El Account Number (Número de cuenta) está en la esquina superior derecha justo debajo del menú Support (Soporte). El ID de cuenta es un número de 12 dígitos. En este caso, supongamos que el ID de la cuenta Desarrollo es 111111111111; debe utilizar un ID de cuenta válido si pretende reconstruir este escenario en su entorno de pruebas.

Para crear un rol en la cuenta Producción que la cuenta Desarrollo pueda utilizar

  1. Inicie sesión en la Consola de administración de AWS como administrador de la cuenta Producción y abra la consola de IAM.

  2. Antes de crear el rol, prepare la política administrada que define los permisos que requiere el rol. Se asocia esta política a la función más adelante en otro paso.

    Debe configurar el acceso de lectura y escritura al bucket productionapp. 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 de la izquierda, elija Policies (Políticas) y, a continuación, seleccione Create Policy (Crear política).

  3. 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, reemplazando el ARN del recurso (arn:aws:s3:::productionapp) por el ARN real correspondiente a su bucket de S3.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] }

    El permiso ListBucket permite a los usuarios ver objetos en el bucket productionapp. Los permisos GetObject, PutObject, DeleteObject permiten a los usuarios ver, actualizar y eliminar contenido del bucket productionapp.

  4. Cuando haya terminado, seleccione Review policy. El validador de políticas notifica los errores de sintaxis.

    nota

    Puede alternar entre las pestañas Visual editor (Editor visual) y JSON en cualquier momento. Sin embargo, si realiza cambios o elige Review policy (Revisar política) en la pestaña Visual editor (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.

  5. En la página Review (Revisar), escriba read-write-app-bucket como nombre de la política. Revise el Summary (Resumen) de la política para ver los permisos concedidos por la política y, a continuación, elija Create policy (Crear política) para guardar el trabajo.

    La nueva política aparece en la lista de políticas administradas.

  6. En el panel de navegación de la izquierda, seleccione Roles y, a continuación, seleccione Create Role (Crear roles).

  7. Elija el tipo de rol Another AWS account (Otra cuenta de AWS).

  8. En Account ID (ID de cuenta), escriba el ID de la cuenta Desarrollo

    En este tutorial, se utiliza el ID de cuenta de ejemplo 111111111111 para la cuenta Desarrollo. Debe utilizar un ID de cuenta válido. Si utiliza un ID de cuenta no 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. Por lo tanto, deje estas opciones desmarcadas. Para obtener más información, consulte Uso de Multi-Factor Authentication (MFA) en AWS

  9. Seleccione Next: Permissions (Siguiente: Permisos) para establecer los permisos que se asociarán al rol.

  10. Seleccione el cuadro situado 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 ha creado. Esto ocultará las políticas creadas por AWS y facilitará en gran medida encontrar la política que está buscando.

    A continuación, elija Next: Tags (Siguiente: Etiquetas).

  11. (Opcional) Añadir metadatos al rol asociando las etiquetas como pares de clave-valor. Para obtener más información acerca del uso de etiquetas en IAM, consulte Etiquetado de entidades de IAM.

  12. Elija Next: Review (Siguiente: Revisión) y escriba UpdateApp como nombre del rol.

  13. (Opcional) En Role descripción, escriba una descripción para la nueva función.

  14. Después de revisar el rol, seleccione Create Role (Crear rol).

    El rol UpdateApp se muestra en la lista de roles.

Ahora debe obtener el nombre de recurso de Amazon (ARN) del rol, que es un identificador exclusivo del rol. Si modifica la política de grupo de los desarrolladores y los evaluadores, debe especifica el ARN del rol para conceder o denegar permisos.

Para obtener el ARN de UpdateApp

  1. En el panel de navegación de la consola de IAM, elija Roles (Funciones).

  2. En la lista de roles, elija el rol UpdateApp.

  3. En la sección Summary (Resumen) del panel de detalles, copie el valor de Role ARN (ARN del rol).

    La cuenta Producción tiene el ID de cuenta 999999999999, por lo que el ARN del rol es arn:aws:iam::999999999999:role/UpdateApp. Asegúrese de dar el ID de cuenta de AWS real de la cuenta "Producción".

En este punto, ha establecido una relación de confianza entre las cuentas Producción y Desarrollo creando un rol en la cuenta Producción que identifica la cuenta Desarrollo como principal de confianza. También ha definido qué pueden hacer los usuarios que cambian al rol UpdateApp.

A continuación, va a modificar los permisos de los grupos.

Paso 2: Conceder acceso al rol

En este punto, los miembros de los grupos Evaluadores y Desarrolladores tienen permisos que les permiten probar libremente aplicaciones en la cuenta Desarrollo. Estos son los pasos necesarios para añadir permisos que permitan cambiar al rol.

Para modificar el grupo Desarrolladores para que puedan cambiar al rol UpdateApp

  1. Inicie sesión como administrador en la cuenta Desarrollo y abra la consola de IAM.

  2. Elija Groups (Grupos) y, a continuación, Developers (Desarrolladores).

  3. Elija la pestaña Permissions (Permisos), amplíe la sección Inline Policies (Políticas integradas) y, a continuación, seleccione Create Group Policy (Crear política de grupo). Si todavía no existe una política insertada, el botón no aparecerá. En su lugar, elija el enlace que se encuentra al final de "To create one, click here".

  4. Elija Custom Policy (Política personalizada) y después haga clic en el botón Select (Seleccionar).

  5. Escriba un nombre de política, como allow-assume-S3-role-in-production.

  6. Añada la siguiente declaración de política para permitir la acción AssumeRole en el rol UpdateApp en la cuenta Producción. Asegúrese de que cambia PRODUCTION-ACCOUNT-ID en el elemento Resource por el ID de cuenta de AWS real de la cuenta Producción.

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    El efecto Allow permite explícitamente al grupo Desarrolladores obtener acceso al rol UpdateApp en la cuenta Producción. Todos los desarrolladores que intenten obtener acceso al rol lo conseguirán.

  7. Elija Apply Policy (Aplicar política) para añadir la política al grupo Desarrolladores.

En la mayoría de los entornos, probablemente el siguiente procedimiento no sea necesario. Si, por el contrario, usa permisos de usuario avanzado, es posible que algunos grupos ya puedan cambiar de rol. En los siguientes procedimientos se muestra cómo añadir un permiso "Deny" al grupo Evaluadores para garantizar que no puedan asumir el rol. Si este procedimiento no es necesario en su entorno, le recomendamos que no lo añada. Los permisos "Deny" hacen que el panorama general de los permisos sea más difícil de administrar y entender. Utilice los permisos "Deny" solo cuando no tenga una mejor opción.

Para modificar el grupo Evaluadores para denegarle el permiso de asumir el rol UpdateApp

  1. Elija Groups (Grupos) y, a continuación, Testers (Probadores).

  2. Elija la pestaña Permissions (Permisos), amplíe la sección Inline Policies (Políticas integradas) y, a continuación, seleccione Create Group Policy (Crear política de grupo).

  3. Elija Custom Policy (Política personalizada) y después haga clic en el botón Select (Seleccionar).

  4. Escriba un nombre de política, como deny-assume-S3-role-in-production.

  5. Añada la siguiente declaración de política para denegar la acción AssumeRole en el rol UpdateApp. Asegúrese de que cambia PRODUCTION-ACCOUNT-ID en el elemento Resource por el ID de cuenta de AWS real de la cuenta Producción.

    { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    El efecto Deny deniega explícitamente al grupo Evaluadores obtener acceso al rol UpdateApp en la cuenta Producción. Todos los evaluadores que intenten obtener acceso al rol recibirán un mensaje de acceso denegado.

  6. Elija Apply Policy (Aplicar política) para añadir la política al grupo Evaluadores.

Ahora, el grupo Desarrolladores tiene permisos para utilizar el rol UpdateApp en la cuenta Producción. El grupo Evaluadores no podrá usar el rol UpdateApp.

A continuación, aprenderá cómo David, un desarrollador, puede obtener acceso al bucket productionapp en la cuenta Producción mediante la Consola de administración de AWS, los comandos de la AWS CLI y la llamada a la API AssumeRole.

Paso 3: Probar el acceso alternando roles

Después de completar los dos primeros pasos de este tutorial, tiene un rol que concede acceso a un recurso en la cuenta Producción. También tiene un grupo en la cuenta Desarrollo cuyos usuarios tienen permiso para usar dicho rol. El rol ya está listo para su uso. 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.

importante

Puede cambiar a un rol únicamente si ha iniciado sesión como usuario de IAM o usuario federado. Además, si lanza una instancia Amazon EC2 para ejecutar una aplicación, la aplicación puede asumir un rol mediante su perfil de instancia. No puede cambiar a un rol si ha iniciado sesión como usuario Usuario de la cuenta raíz de AWS.

Cambio de roles (consola)

Si David necesita trabajar en el entorno de producción en la Consola de administración de AWS, puede hacerlo utilizando Switch Role (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. A continuación, puede utilizar la consola para trabajar con el bucket productionapp, pero no puede trabajar con ningún otro recurso de Producción. Aunque David utiliza el rol, tampoco puede hacer uso de sus privilegios de usuario avanzado en la cuenta Desarrollo. Esto se debe a que no puede haber más de un conjunto de permisos en vigor a la vez.

importante

El cambio de roles mediante la Consola de administración de AWS solo funciona en el caso de las cuentas que no requieran un ExternalId. Si concede acceso a su cuenta a terceros y exige un ExternalId en un elemento Condition de su política de permisos, el tercero podrá obtener acceso a su cuenta únicamente usando la API de AWS o una herramienta de línea de comandos. El tercero no puede utilizar la consola, ya que no puede proporcionar un valor para ExternalId. Para obtener más información sobre este caso, consulte Cómo utilizar un ID externo al otorgar acceso a los recursos de AWS a terceros y Cómo habilitar el acceso entre cuentas a la Consola de administración de AWS en el Blog de seguridad de AWS.

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 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 Role (Cambiar rol) y habrá acabado.

  • 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). David tiene que escribirlos manualmente para cambiar de rol. Esto se muestra en el procedimiento siguiente.

Para asumir un rol

  1. David inicia sesión en la consola de AWS con su usuario normal que se encuentra en el grupo Desarrollo.

  2. Elige el enlace que su administrador le ha enviado por correo electrónico. Esto lo lleva 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—

    Elige su nombre (menú Identity) 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, primero irá a la página Switch Role (Cambiar rol). Esta página proporciona información adicional acerca de cómo el cambio de rol puede habilitar a los usuarios para que administren recursos entre cuentas de AWS. David debe hacer clic en el botón Switch Role (Cambiar rol) de esta página para completar el resto de este procedimiento.

  3. A continuación, para poder obtener acceso al rol, David debe escribir manualmente el número de ID de la cuenta Producción (999999999999) y el nombre del rol (UpdateApp).

    Además, para ser consciente del rol (y permisos asociados) que están actualmente activos, David escribe PRODUCTION en el cuadro de texto Display Name (Nombre que mostrar), selecciona la opción de color rojo y después elige Switch Role (Cambiar rol).

  4. 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 UpdateApp tenga permisos.

  5. Cuando acabe su trabajo, David puede restaurar sus permisos originales. Para ello, elige el nombre de visualización del rol PRODUCTION en la barra de navegación y, a continuación, elige Back to David @ 111111111111.

  6. La siguiente vez que David quiera cambiar de rol y elija el menú Identity en la barra de navegación, verá que la entrada PRODUCTION siga estando ahí. Solo tiene que elegir esa entrada para cambiar de rol inmediatamente sin tener que volver a escribir el ID de la cuenta y el nombre de rol.

Cambio de roles (AWS CLI)

Si David necesita trabajar en la línea de comandos en el entorno Producción, puede hacerlo utilizando la AWS 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 utiliza el rol, no puede utilizar sus privilegios de usuario avanzado en la cuenta Desarrollo, ya que solo puede haber 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 en la AWS Command Line Interface Guía del usuario.

  2. Comienza el proceso de cambio de rol ejecutando el siguiente comando para cambiar al rol UpdateApp en la cuenta Producción. El administrador que ha creado el rol le ha proporcionado 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/UpdateApp" --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" } }
  3. David ve los tres elementos que necesita en la sección Credentials 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. No puede ejecutar el aws configure, ya que no admite la captura del token de sesión. Sin embargo, puede escribir 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.

  4. Para añadir los tres valores al entorno, David corta y pega la salida del paso anterior en los comandos siguientes. Tenga en cuenta que 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.

    nota

    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 Mac, se utiliza el comando "export". Las demás partes del ejemplo son válidas en los tres entornos.

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

  5. Ejecute el comando para obtener acceso a los recursos de la cuenta Producción. En este ejemplo, David solo genera una lista del contenido de su bucket de S3 con el siguiente comando.

    aws s3 ls s3://productionapp

    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 necesarios para hacer referencia a sus recursos.

Uso de AssumeRole (API de AWS)

Cuando David necesita realizar una actualización en la cuenta Producción desde el código, llama a AssumeRole para asumir el rol UpdateApp. La llamada devuelve credenciales temporales que puede utilizar para obtener acceso al bucket productionapp de la cuenta Producción. Con estas credenciales, David puede realizar llamadas a la API para actualizar el bucket productionapp. Sin embargo, no puede realizar llamadas a la API para obtener acceso a otros recursos de la cuenta Producción, aunque tenga permisos de usuario avanzado en la cuenta Desarrollo.

Para asumir un rol

  1. David llama a AssumeRole como parte de una aplicación. Debe especificar el ARN UpdateApp: arn:aws:iam::999999999999:role/UpdateApp.

    La respuesta de la llamada AssumeRole contiene las credenciales temporales con un AccessKeyId, una SecretAccessKey y un plazo de Expiration que indica cuándo caducan las credenciales y debe solicitar nuevas.

  2. Con las credenciales temporales, David realiza una llamada s3:PutObject para actualizar el bucket productionapp. Transfiere las credenciales a la llamada a la API como el parámetro AuthParams. Dado que las credenciales temporales del rol tienen acceso de solo lectura y escritura al bucket productionapp, se deniegan todas las demás acciones de la cuenta Producción.

Para obtener código de ejemplo (mediante Python), consulte Cambio a un rol de IAM (API de AWS).

  • Para obtener más información acerca de los grupos y usuarios de IAM, consulte Identidades (usuarios, grupos y roles).

  • Para obtener más información sobre la creación de buckets de Amazon S3, consulte Crear un bucket en la Guía de introducción a Amazon Simple Storage Service.

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. Después ha modificado una política de grupo para controlar qué usuarios de IAM pueden obtener acceso al rol. Como resultado, los desarrolladores de la cuenta Desarrollo pueden realizar actualizaciones en el bucket productionapp de la cuenta Producción usando credenciales temporales.