# Creación de roles de IAM Para crear un rol, puede utilizar Consola de administración de AWS, AWS CLI, Tools for Windows PowerShell o la API de IAM. Si utiliza la Consola de administración de AWS, un asistente le guiará por los pasos de creación de un rol. El asistente varía ligeramente según si crea un rol para un servicio de AWS, una Cuenta de AWS o una entidad principal federada de SAML u OIDC. **Roles para usuarios de IAM** Cree este rol para delegar permisos en su Cuenta de AWS o a roles definidos en otras Cuentas de AWS que posea. Un usuario de una cuenta puede cambiar de rol en la misma cuenta o en una cuenta diferente. Al utilizar el rol, el usuario solo puede realizar las acciones y obtener acceso únicamente a los recursos permitidos por el rol; sus permisos originales de usuario se suspenden. Si el usuario deja de utilizar el rol, sus permisos originales se restablecen. Para obtener más información, consulte [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md). A fin de obtener más información sobre la creación de roles para el acceso entre cuentas, consulte [Crear un rol mediante políticas de confianza personalizadas](id_roles_create_for-custom.md). **Roles para servicios de AWS** Cree este rol para delegar permisos a un servicio que pueda realizar acciones en su nombre. El [rol de servicio](id_roles.md#iam-term-service-role) que transfiera a un servicio debe tener una política de IAM con los permisos que autoricen a ese servicio a realizar las acciones que tiene asociadas. Se requieren distintos permisos para cada servicio de AWS. Para obtener más información sobre la creación de roles de servicio, consulte [Crear un rol para delegar permisos a un servicio de AWS](id_roles_create_for-service.md). Para obtener más información sobre la creación de roles vinculados a servicios, consulte [Creación de un rol vinculado al servicio](id_roles_create-service-linked-role.md). **Roles para la federación de identidades** Cree este rol para delegar permisos a los usuarios que ya tienen identidades fuera de AWS. Cuando se utiliza un proveedor de identidad, no es necesario crear un código de inicio de sesión personalizado ni administrar sus propias identidades de usuario. Sus usuarios externos inician sesión a través de un IdP, y usted puede conceder permisos a las identidades externas para utilizar los recursos de AWS en su cuenta. Los proveedores de identidades lo ayudan a proteger su cuenta de AWS, ya que no tiene que distribuir ni integrar en su aplicación credenciales de seguridad a largo plazo, como las claves de acceso. Para obtener más información, consulte [Creación de un rol para un proveedor de identidad externo](id_roles_create_for-idp.md). # Creación de un rol para delegar permisos a un usuario de IAM Puede utilizar roles de IAM para proporcionar acceso a sus recursos de AWS. Con roles de IAM puede establecer relaciones de *confianza* entre la cuenta que confía y otras cuentas de *confianza* de AWS. La cuenta que confía posee el recurso al que se obtiene acceso y la cuenta de confianza incluye los usuarios que necesitan obtener acceso al recurso. Sin embargo, es posible que otra cuenta sea propietaria de un recurso de su cuenta. Por ejemplo, la cuenta que confía podría permitir a la cuenta de confianza crear recursos, como, por ejemplo, crea objetos en un bucket de Amazon S3. En ese caso, la cuenta que crea el recurso es la propietaria del recurso y controla quién pueden tener acceso a dicho recurso. Después de crear la relación de confianza, un usuario de IAM o una aplicación de la cuenta de confianza pueden utilizar la operación AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) de la API. Esta operación proporciona credenciales de seguridad temporales que permiten el acceso a los recursos de AWS de su cuenta. Usted puede controlar ambas cuentas o un tercero puede controlar la cuenta con los usuarios. Si la otra cuenta con los usuarios se encuentra en una Cuenta de AWS que usted no controla, puede utilizar el atributo `externalId`. El ID externo puede ser cualquier palabra o número acordados entre usted y el administrador de la cuenta de terceros. Esta opción agrega automáticamente una condición a la política de confianza que permite al usuario asumir el rol únicamente si la solicitud incluye el correcto `sts:ExternalID`. Para obtener más información, consulte [Acceder a las Cuentas de AWS que le pertenezcan a terceros](id_roles_common-scenarios_third-party.md). Para obtener información sobre cómo utilizar los roles para delegar permisos, consulte [Términos y conceptos de roles](id_roles.md#id_roles_terms-and-concepts). Para obtener más información sobre el uso de un rol de servicio para permitir que los servicios obtengan acceso a los recursos de su cuenta, consulte [Crear un rol para delegar permisos a un servicio de AWS](id_roles_create_for-service.md). ## Creación de un rol de IAM (consola) Puede utilizar la Consola de administración de AWS para crear un rol que un usuario de IAM pueda asumir. Por ejemplo, suponga que su organización tiene varias Cuentas de AWS para aislar un entorno de desarrollo de uno de producción. Para información general sobre cómo crear un rol que permita a usuarios de la cuenta de desarrollo acceder a los recursos de la cuenta de producción, consulte [Situación de ejemplo en la que se usan cuentas de desarrollo y producción separadas](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example). **Permisos mínimos** Para realizar los siguientes pasos, debe tener al menos los siguientes permisos IAM: `access-analyzer:ValidatePolicy` `iam:AttachRolePolicy` `iam:CreatePolicy` `iam:CreateRole` `iam:GetAccountSummary` `iam:GetPolicy` `iam:GetPolicyVersion` `iam:GetRole` `iam:ListAccountAliases` `iam:ListAttachedRolePolicies` `iam:ListOpenIDConnectProviders` `iam:ListPolicies` `iam:ListRolePolicies` `iam:ListRoles` `iam:ListRoleTags` `iam:ListSAMLProviders` ------ #### [ Console ] 1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la consola, elija **Roles** y, a continuación, seleccione **Crear rol**. 1. Elija el tipo de rol de **Cuenta de AWS**. 1. Para crear un rol para la cuenta, elija **Esta cuenta**. Para crear un rol para otra cuenta, elija **Otra Cuenta de AWS** e ingrese el **ID de cuenta** al que desea conceder acceso a los recursos. El administrador de la cuenta especificada puede conceder permiso para asumir este rol a cualquier usuario de IAM en esa cuenta. Para ello, el administrador asocia una política al usuario o grupo que concede permiso para la acción `sts:AssumeRole`. Esta política debe especificar el ARN del rol como `Resource`. 1. Si concede permisos a los usuarios desde una cuenta que no controla y los usuarios van a asumir este rol mediante programación, seleccione **Requerir ID externo**. El ID externo puede ser cualquier palabra o número acordados entre usted y el administrador de la cuenta de terceros. Esta opción agrega automáticamente una condición a la política de confianza que permite al usuario asumir el rol únicamente si la solicitud incluye el correcto `sts:ExternalID`. Para obtener más información, consulte [Acceder a las Cuentas de AWS que le pertenezcan a terceros](id_roles_common-scenarios_third-party.md). **importante** Si elige esta opción, restringe el acceso al rol únicamente a través de la API de AWS CLI, Tools for Windows PowerShell o API de AWS. Esto se debe a que no puede utilizar la consola de AWS para cambiar a un rol que tiene una condición `externalId` en su política de confianza. Sin embargo, puede crear este tipo de acceso mediante programación si escribe un script o una aplicación con el correspondiente SDK. Para obtener más información y un script de muestra, consulte [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. 1. Si desea restringir el rol a aquellos usuarios que inicien sesión con autenticación multifactor (MFA), seleccione **Requerir MFA**. De esta forma se agrega una condición a la política de confianza del rol que comprueba si se produce un inicio de sesión con MFA. Un usuario que desee asumir el rol debe iniciar sesión con una contraseña temporal de uso único desde un dispositivo MFA configurado. Los usuarios sin autenticación MFA no pueden asumir el rol. Para obtener más información acerca de MFA, consulte [Autenticación multifactor de AWS en IAM](id_credentials_mfa.md) 1. Elija **Siguiente**. 1. IAM incluye una lista de las políticas administradas por AWS y de las políticas administradas por el cliente de cada cuenta. Seleccione la política que desea utilizar como política de permisos o elija **Crear política** para abrir una pestaña nueva del navegador y crear una política nueva desde cero. Para obtener más información, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start). Después de crear la política, cierre esa pestaña y vuelva a la pestaña original. Seleccione la casilla situada junto a las políticas de permisos que desea conceder a cualquier persona que asuma el rol. Si lo prefiere, puede optar por no seleccionar ninguna política en este momento y asociar las políticas al rol más adelante. De forma predeterminada, un rol no tiene permisos. 1. (Opcional) Configure un [límite de permisos](access_policies_boundaries.md). Esta es una característica avanzada. Abra la sección **Configurar límite de permisos** y elija **Utilizar un límite de permisos para controlar los permisos que puede tener el rol como máximo**. Seleccione la política que desea utilizar para el límite de permisos. 1. Elija **Siguiente**. 1. Escriba un nombre para el rol en **Nombre de rol**. Los nombres de rol deben ser únicos en su Cuenta de AWS. Cuando se utiliza un nombre de rol en una política o como parte de un ARN, el nombre del rol distingue entre mayúsculas y minúsculas. Cuando los clientes ven un nombre de rol en la consola, por ejemplo, durante el proceso de inicio de sesión, el nombre del rol no distingue entre mayúsculas y minúsculas. Dado que varias entidades pueden hacer referencia al rol, no se puede editar el nombre del rol una vez que se crea. 1. (Opcional) En **Descripción**, ingrese una descripción para el nuevo rol. 1. Elija **Editar** en las secciones **Paso 1: seleccionar entidades de confianza** o **Paso 2: agregar permisos** para editar los casos de uso y los permisos del rol. Volverá a las páginas anteriores para realizar las modificaciones. 1. De manera opcional, agregue metadatos al rol asociando 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. Revise el rol y, a continuación, seleccione **Crear rol**. **importante** Recuerde que esto es solo la primera mitad de la configuración necesaria. También debe conceder permisos a determinados usuarios de la cuenta de confianza para cambiar al rol en la consola o para asumir el rol mediante programación. Para obtener más información acerca de este paso, consulte [Conceder a un usuario permisos para cambiar de rol](id_roles_use_permissions-to-switch.md). ------ ## Creación de un rol de IAM (AWS CLI) Para crear un rol desde la AWS CLI se deben seguir varios pasos. Si utiliza la consola para crear un rol, muchos de los pasos se realizan automáticamente, pero con la AWS CLI deberá realizar cada paso usted mismo. Debe crear el rol y, a continuación, asignar una política de permisos al rol. Si lo prefiere, también puede configurar el [límite de permisos](access_policies_boundaries.md) para el rol. **Para crear un rol para el acceso entre cuentas (AWS CLI)** 1. Crear un rol: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 1. Asociar una política de permisos administrada al rol: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) o Crear una política de permisos insertada para el rol: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) 1. (Opcional) Añadir los atributos personalizados al rol asociando etiquetas: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Para obtener más información, consulte [Administrar etiquetas en roles de IAM (AWS CLI o API de AWS)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Opcional) Configurar el [límite de permisos](access_policies_boundaries.md) para el rol: [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. El siguiente ejemplo muestra los dos primeros pasos, que también son los más comunes, para crear un rol entre cuentas en un entorno sencillo. Este ejemplo permite a cualquier usuario de la cuenta `123456789012` asumir el rol y ver el bucket de `example_bucket` Amazon S3. Este ejemplo también supone que se está utilizando un equipo cliente con Windows y que ya se ha configurado la interfaz de línea de comandos con las credenciales de la cuenta y la región. Para obtener más información, consulte [Configuración de la interfaz de línea de comandos de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). En este ejemplo, incluya la siguiente política de confianza en el primer comando al crear el rol. Esta política de confianza permite a los usuarios de la cuenta `123456789012` asumir el rol utilizando la operación `AssumeRole`, pero solo si el usuario proporciona la autenticación MFA utilizando los parámetros `SerialNumber` y `TokenCode`. Para obtener más información acerca de MFA, consulte [Autenticación multifactor de AWS en IAM](id_credentials_mfa.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } ] } ``` ------ **importante** Si el elemento `Principal` incluye el ARN de un determinado usuario o rol de IAM, dicho ARN se transforma en un ID exclusivo de entidad principal cuando se guarda la política. Esto ayuda a mitigar el riesgo de que alguien aumente sus permisos eliminando o volviendo a crear el rol o usuario. Normalmente, este ID no se muestra en la consola porque también existe una transformación inversa al ARN cuando se muestra la política de confianza. Sin embargo, si se elimina el rol o el usuario, el ID de entidad principal aparece en la consola porque AWS ya no puede volver a asignarlo a un ARN. Por lo tanto, si elimina y vuelve a crear un usuario o rol al que se hace referencia en un elemento `Principal` de la política de confianza, debe editar el rol para sustituir el ARN. Cuando utilice el segundo comando, debe asociar una política administrada existente al rol. La siguiente política de permisos permite a cualquiera que asuma el rol realizar únicamente la acción `ListBucket` en el bucket de Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } ] } ``` ------ Para crear este rol `Test-UserAccess-Role`, primero debe guardar la política de confianza anterior con el nombre `trustpolicyforacct123456789012.json` en la carpeta `policies` del disco duro local `C:`. A continuación, guarde el política de permisos anterior como una política administrada por el cliente en su Cuenta de AWS con el nombre `PolicyForRole`. A continuación, puede utilizar los comandos siguientes para crear el rol y asociarle la política administrada. ``` # Create the role and attach the trust policy file that allows users in the specified account to assume the role. $ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json # Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do. $ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole ``` **importante** Recuerde que esto es solo la primera mitad de la configuración necesaria. También debe conceder permisos a los usuarios individuales de la cuenta de confianza para cambiar al rol. Para obtener más información acerca de este paso, consulte [Conceder a un usuario permisos para cambiar de rol](id_roles_use_permissions-to-switch.md). Después de crear el rol y concederle permisos para realizar tareas de AWS u obtener acceso a los recursos de AWS, cualquier usuario de la cuenta `123456789012` puede asumir el rol. Para obtener más información, consulte [Cambiar a un rol de IAM (AWS CLI)](id_roles_use_switch-role-cli.md). ## Creación de un rol de IAM (API de AWS) Para crear un rol desde la API de AWS se deben seguir varios pasos. Si utiliza la consola para crear un rol, muchos de los pasos se realizan automáticamente, pero con la API deberá realizar cada paso usted mismo. Debe crear el rol y, a continuación, asignar una política de permisos al rol. Si lo prefiere, también puede configurar el [límite de permisos](access_policies_boundaries.md) para el rol. **Para crear un rol en código (API de AWS)** 1. Creación de un rol: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) Para la política de confianza del rol, puede especificar una ubicación de archivo. 1. Asociar una política de permisos administrada al rol: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) o Crear una política de permisos insertada para el rol: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) **importante** Recuerde que esto es solo la primera mitad de la configuración necesaria. También debe conceder permisos a los usuarios individuales de la cuenta de confianza para cambiar al rol. Para obtener más información acerca de este paso, consulte [Conceder a un usuario permisos para cambiar de rol](id_roles_use_permissions-to-switch.md). 1. (Opcional) Añadir los atributos personalizados al usuario asociando etiquetas: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Para obtener más información, consulte [Administrar etiquetas en usuarios de IAM (AWS CLI o API de AWS)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Opcional) Configuración del [límite de permisos](access_policies_boundaries.md) para el rol: [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. Después de crear el rol y concederle permisos para realizar tareas de AWS u obtener acceso a los recursos de AWS, debe conceder permisos a los usuarios de la cuenta para que puedan asumir el rol. Para obtener más información sobre cómo asumir un rol, consulte [Cambiar a un rol de IAM (API de AWS)](id_roles_use_switch-role-api.md). ## Creación de un rol de IAM (AWS CloudFormation) Para obtener información acerca de cómo crear un rol de IAM en AWS CloudFormation, consulte la [referencia de recursos y propiedades](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) y los [ejemplos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) en la *Guía del usuario de AWS CloudFormation*. Para obtener más información acerca de las plantillas de IAM en AWS CloudFormation, consulte [fragmentos de plantilla AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html) en la *Guía del usuario de AWS CloudFormation*. # Crear un rol para delegar permisos a un servicio de AWS Muchos servicios de AWS requieren que utilice roles para permitir que el servicio obtenga acceso a los recursos de otros servicios en su nombre. Un rol que asume un servicio para realizar acciones en su nombre se denomina [rol de servicio](id_roles.md#iam-term-service-role). Si un rol tiene un fin especializado para un servicio, se categoriza como [rol de servicio vinculado](id_roles.md#iam-term-service-linked-role). Para ver qué servicios son compatibles con el uso de roles vinculados a servicios, o si un servicio admite algún tipo de credenciales temporales, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md). Para obtener información sobre cómo un servicio determinado utiliza los roles, elija el nombre del servicio en la tabla para ver la documentación correspondiente a dicho servicio. Al configurar el permiso `PassRole`, debe asegurarse de que un usuario no pase un rol en el que el rol tenga más permisos de los que usted desea que tenga el usuario. Por ejemplo, es posible que a Alice no se le permita realizar ninguna acción de Amazon S3. Si Alice pudiera transferir un rol a un servicio que permita acciones de Amazon S3, el servicio podría realizar acciones de Amazon S3 en su nombre al ejecutar el trabajo. Para obtener información sobre cómo los roles le pueden ayudar a delegar permisos, consulte [Términos y conceptos de roles](id_roles.md#id_roles_terms-and-concepts). ## Permisos del rol de servicio Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear o editar una función de servicio. **nota** El ARN de un rol vinculado a un servicio incluye una entidad principal del servicio, que se indica en las políticas siguientes como `SERVICE-NAME.amazonaws.com`. No intente adivinar la entidad principal del servicio, ya que distingue entre mayúsculas y minúsculas y su formato puede variar para los distintos servicios de AWS. Para ver el elemento principal de un servicio, consulte la documentación correspondiente su rol vinculado a servicio. **Para permitir a una entidad de IAM cree un rol vinculado a un servicio específico** Agregue la siguiente política a la entidad de IAM que necesite crear la función de servicio. Esta política le permite crear un rol de servicio para el servicio especificado y con un nombre específico. A continuación, puede asociar políticas administradas o insertadas al rol. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" } ] } ``` ------ **Cómo permitir a una entidad de IAM crear un rol de servicio** AWS recomienda permitir solo a los administradores crear cualquier rol de servicio. Una persona con permisos para crear un rol y adjuntar cualquier política puede escalar sus propios permisos. En su lugar, cree una política que les permita crear solo los roles que necesitan o haga que un administrador cree el rol de servicio en su nombre. Para adjuntar una política que permita a un administrador acceder a toda la Cuenta de AWS, utilice la política administrada [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) de AWS. **Cómo permitir a una entidad de IAM editar un rol de servicio** Agregue la siguiente política a la entidad de IAM que necesite editar la función de servicio. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EditSpecificServiceRole", "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "iam:PutRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" }, { "Sid": "ViewRolesAndPolicies", "Effect": "Allow", "Action": [ "iam:GetPolicy", "iam:ListRoles" ], "Resource": "*" } ] } ``` ------ **Para permitir a una entidad de IAM eliminar una función de servicio específico** Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que necesite eliminar la función de servicio especificado. ``` { "Effect": "Allow", "Action": "iam:DeleteRole", "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" } ``` **Cómo permitir a una entidad de IAM eliminar cualquier rol de servicio** AWS recomienda permitir solo a los administradores eliminar cualquier rol de servicio. En su lugar, cree una política que les permita eliminar solo los roles que necesitan o haga que un administrador elimine el rol de servicio en su nombre. Para adjuntar una política que permita a un administrador acceder a toda la Cuenta de AWS, utilice la política administrada [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) de AWS. ## Creación de un rol para un servicio de AWS (consola) Puede utilizar la Consola de administración de AWS para crear un rol para un servicio. Algunos servicios admiten más de un rol de servicio. Por lo tanto, recomendamos que consulte la [documentación de AWS](https://docs.aws.amazon.com/) relacionada con su servicio para ver qué caso de uso debe elegir. Puede obtener más información acerca de cómo asignar las políticas de confianza y de permisos necesarias para el rol, para que el servicio pueda asumir el rol en su nombre. Los pasos que puede utilizar para controlar los permisos para el rol pueden variar en función de cómo defina el servicio los casos de uso y de si se crea o no un rol vinculado al servicio. ------ #### [ Console ] **Cómo crear un rol para un Servicio de AWS (consola de IAM)** 1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la consola de IAM, seleccione **Roles** y, a continuación, elija **Crear rol**. 1. En **Tipo de entidad de confianza**, elija **Servicio de AWS**. 1. En **Servicio o caso de uso**, seleccione un servicio y, a continuación, el caso de uso. Los casos de uso son definidos por el servicio de modo tal que ya incluyen la política de confianza que el servicio mismo requiere. 1. Elija **Siguiente**. 1. Para las **Políticas de permisos**, las opciones dependen del caso de uso que haya seleccionado: + Si el servicio define los permisos para el rol, no puede seleccionar políticas de permisos. + Seleccione entre un conjunto limitado de políticas de permisos. + Seleccione una de todas las políticas de permisos. + No seleccione políticas de permisos en este momento. Después de crear el rol, genere las políticas y luego asócielas al rol. 1. (Opcional) Configure un [límite de permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Se trata de una característica avanzada que está disponible para los roles de servicio, pero no para los roles vinculados a servicios. 1. Abra la sección **Configurar límite de permisos** y, a continuación, elija **Utilizar un límite de permisos para controlar los permisos que puedes tener el rol como máximo**. IAM incluye una lista de las políticas administradas por AWS y de las políticas administradas por el cliente de cada cuenta. 1. Seleccione la política que desea utilizar para el límite de permisos. 1. Elija **Siguiente**. 1. Para **Nombre del rol**, las opciones varían según el servicio: + Si el servicio define el nombre del rol, no podrá editarlo. + Si el servicio define un prefijo para el nombre del rol, puede ingresar un sufijo opcional. + Si el servicio no define el nombre del rol, podrá nombrarlo usted mismo. **importante** Cuando asigne un nombre a un rol, tenga en cuenta lo siguiente: Los nombres de rol deben ser únicos dentro de su Cuenta de AWS, y no se puedesn hacer únicos mediante mayúsculas y minúsculas. Por ejemplo, no puedes crear roles denominados tanto **PRODROLE** como **prodrole**. Cuando se utiliza un nombre de rol en una política o como parte de un ARN, el nombre de rol distingue entre mayúsculas y minúsculas, sin embargo, cuando un nombre de rol les aparece a los clientes en la consola, como por ejemplo durante el proceso de inicio de sesión, el nombre de rol no distingue entre mayúsculas y minúsculas. Dado que otras entidades podrían hacer referencia al rol, no es posible editar el nombre del rol una vez creado. 1. (Opcional) **En Descripción**, ingrese una descripción para el rol. 1. (Opcional) Para editar los casos de uso y los permisos de la función, en las secciones **Paso 1: Seleccionar entidades confiables** o en **Paso 2: Agregar permisos**, elija **Editar**. 1. (Opcional) Para ayudar a identificar, organizar o buscar el rol, agregue etiquetas como pares clave-valor. Para obtener más información sobre el uso de etiquetas en IAM, consulte [Etiquetas para recursos de AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) en la *Guía del usuario de IAM*. 1. Revise el rol y, a continuación, elija **Crear rol**. ------ ## Creación de un rol para un servicio (AWS CLI) Para crear un rol desde la AWS CLI se deben seguir varios pasos. Si utiliza la consola para crear un rol, muchos de los pasos se realizan automáticamente, pero con la AWS CLI deberá realizar cada paso usted mismo. Debe crear el rol y, a continuación, asignar una política de permisos al rol. Si el servicio con el que está trabajando es Amazon EC2 también deberá crear un perfil de instancia y agregarle el rol. Si lo prefiere, también puede configurar el [límite de permisos](access_policies_boundaries.md) para el rol. **Para crear un rol para un servicio de AWS desde la AWS CLI** 1. Los siguientes comandos `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` crean un rol llamado *Test-Role* y le asigna una política de confianza: `aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json` 1. Asociar una política de permisos administrada al rol: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Por ejemplo, el siguiente comando `attach-role-policy` adjunta la política administrada AWS denominada `ReadOnlyAccess` en el rol de IAM denominado `ReadOnlyRole`: `aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole` o Crear una política de permisos insertada para el rol: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) Para agregar una política de permisos insertada, consulte el siguiente ejemplo: `aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json` 1. (Opcional) Añadir los atributos personalizados al rol asociando etiquetas: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Para obtener más información, consulte [Administrar etiquetas en roles de IAM (AWS CLI o API de AWS)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Opcional) Configurar el [límite de permisos](access_policies_boundaries.md) para el rol: [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. Si va a utilizar el rol con Amazon EC2 o con otro servicio de AWS que utiliza Amazon EC2, debe almacenar el rol en un perfil de instancias. Un perfil de instancias es un contenedor para un rol que se puede asociar a una instancia de Amazon EC2 cuando se lanza. Un perfil de instancia puede contener un único rol y dicho límite no se puede aumentar. Si crea el rol con la Consola de administración de AWS, el perfil de instancia se crea con el mismo nombre que el rol. Para obtener más información sobre los perfiles de instancia, consulte [Utilizar perfiles de instancia](id_roles_use_switch-role-ec2_instance-profiles.md). Para obtener información sobre cómo inicializar una instancia de EC2 con un rol, consulte [Control del acceso a los recursos de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) en la *Guía del usuario de Amazon EC2*. **Para crear un perfil de instancia y almacenar el rol en él (AWS CLI)** 1. Crear un perfil de instancia: [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) 1. Añadir el rol al perfil de instancia: [aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) En el siguiente ejemplo de conjunto de comandos de la AWS CLI, se muestran los dos primeros pasos para crear un rol y asociar permisos. También muestra los dos pasos para crear un perfil de instancia y añadir el rol al perfil. Esta política de confianza de ejemplo permite al servicio Amazon EC2 asumir el rol y ver el bucket de `example_bucket` Amazon S3. El ejemplo también supone que se está utilizando un equipo cliente con Windows y que ya se ha configurado la interfaz de línea de comandos con las credenciales y región de la cuenta. Para obtener más información, consulte [Configuración de la interfaz de línea de comandos de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). En este ejemplo, incluya la siguiente política de confianza en el primer comando al crear el rol. Esta política de confianza permite que el servicio Amazon EC2 asuma el rol. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole" } } ``` ------ Cuando utilice el segundo comando, debe asociar una política de permisos al rol. La siguiente política de permisos de ejemplo permite al rol realizar únicamente la acción `ListBucket` en el bucket de Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } } ``` ------ Para crear el rol `Test-Role-for-EC2`, primero debe guardar la política de confianza anterior con el nombre `trustpolicyforec2.json` y la política de permisos anterior con el nombre `permissionspolicyforec2.json` en el directorio `policies` del disco duro local `C:`. A continuación, puede utilizar los siguientes comandos para crear el rol, asociar la política, crear el perfil de instancia y añadir el rol al perfil de instancia. ``` # Create the role and attach the trust policy that allows EC2 to assume this role. $ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json # Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do. $ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json # Create the instance profile required by EC2 to contain the role $ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3 # Finally, add the role to the instance profile $ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2 ``` Al lanzar la instancia EC2, especifique el nombre de perfil de instancia en la página **Configurar detalles de la instancia** si utiliza la consola de AWS. Si utiliza el comando de la CLI `aws ec2 run-instances`, especifique el parámetro `--iam-instance-profile`. ## Creación de un rol para un servicio (API de AWS) Para crear un rol desde la API de AWS se deben seguir varios pasos. Si utiliza la consola para crear un rol, muchos de los pasos se realizan automáticamente, pero con la API deberá realizar cada paso usted mismo. Debe crear el rol y, a continuación, asignar una política de permisos al rol. Si el servicio con el que está trabajando es Amazon EC2 también deberá crear un perfil de instancia y agregarle el rol. Si lo prefiere, también puede configurar el [límite de permisos](access_policies_boundaries.md) para el rol. **Para crear un rol para un servicio de AWS (API de AWS)** 1. Creación de un rol: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) Para la política de confianza del rol, puede especificar una ubicación de archivo. 1. Asociar una política de permisos administrada al rol: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) o Crear una política de permisos insertada para el rol: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) 1. (Opcional) Añadir los atributos personalizados al usuario asociando etiquetas: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Para obtener más información, consulte [Administrar etiquetas en usuarios de IAM (AWS CLI o API de AWS)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Opcional) Configuración del [límite de permisos](access_policies_boundaries.md) para el rol: [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. Si va a utilizar el rol con Amazon EC2 o con otro servicio de AWS que utiliza Amazon EC2, debe almacenar el rol en un perfil de instancias. Un perfil de instancia es un contenedor para un rol. Cada perfil de instancia solo puede contener un único rol y dicho límite no se puede superar. Si crea el rol en la Consola de administración de AWS, el perfil de instancia se crea con el mismo nombre que el rol. Para obtener más información sobre los perfiles de instancia, consulte [Utilizar perfiles de instancia](id_roles_use_switch-role-ec2_instance-profiles.md). Para obtener información sobre cómo inicializar una instancia de Amazon EC2 con un rol, consulte [Control del acceso a los recursos de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) en la *Guía del usuario de Amazon EC2*. **Para crear un perfil de instancia y almacenar el rol en él (API de AWS)** 1. Crear un perfil de instancia: [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) 1. Añadir el rol al perfil de instancia: [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) # Creación de un rol vinculado al servicio Un rol vinculado a un servicio es un tipo único de rol de IAM que está vinculado directamente a un servicio de AWS. Los roles vinculados a servicios son predefinidos por el servicio e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre. El servicio vinculado también define cómo crear, modificar y eliminar un rol vinculado a un servicio. Un servicio podría crear el rol automáticamente o eliminarlo. Podría permitirle crear, modificar o eliminar el rol como parte de un asistente o proceso del servicio. También podría exigir que utilice IAM para crear o eliminar el rol. Independientemente del método, los roles vinculados a servicios simplifican la configuración de un servicio porque ya no tendrá que agregar manualmente los permisos necesarios para que el servicio complete acciones en su nombre. **nota** Recuerde que los roles de servicio son diferentes a los roles vinculados a servicios. Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que asume un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Crear un rol para delegar permisos a un Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*. Un rol vinculado a servicios es un tipo de rol de servicio que está vinculado a un Servicio de AWS. El servicio puede asumir el rol para realizar una acción en su nombre. Los roles vinculados a servicios aparecen en la Cuenta de AWS y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de los roles vinculados a servicios. El servicio vinculado define los permisos de los roles vinculados con el servicio mismo y, a menos que esté definido de otra manera, solo ese servicio puede asumir los roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda asociar a ninguna otra entidad de IAM. Antes de eliminar las funciones, debe borrar antes sus recursos relacionados. Esto ayuda a impedir que elimine accidentalmente el permiso para acceder a los recursos. **sugerencia** Para obtener información sobre los servicios que admiten el uso de roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md) y busque los servicios que tengan **Yes **en la columna **Service-Linked Role**. Elija una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión. ## Permisos de roles vinculados a servicios Debe configurar permisos para que una entidad de IAM (usuario, grupo o función) permita al usuario o rol crear o editar el rol vinculado al servicio. **nota** El ARN de un rol vinculado a un servicio incluye una entidad principal del servicio, que se indica en las políticas siguientes como `SERVICE-NAME.amazonaws.com`. No intente adivinar la entidad principal del servicio, ya que distingue entre mayúsculas y minúsculas y su formato puede variar para los distintos servicios de AWS. Para ver el elemento principal de un servicio, consulte la documentación correspondiente su rol vinculado a servicio. **Para permitir a una entidad de IAM que cree un rol vinculado a un servicio específico** Agregue la siguiente política a la entidad de IAM que necesite crear el rol vinculado con un servicio. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*", "Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}} }, { "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*" } ] } ``` ------ **Para permitir a una entidad de IAM crear un rol vinculado a cualquier servicio** Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que necesite crear un rol vinculado con un servicio o cualquier función de servicio que incluya las políticas necesarias. Esta instrucción de política no permite la entidad IAM adjunte una política al rol. ``` { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Para permitir a una entidad IAM editar la descripción de cualquier función de servicio de servicio** Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que necesite editar la descripción de un rol vinculado con un servicio o cualquier función de servicio. ``` { "Effect": "Allow", "Action": "iam:UpdateRoleDescription", "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Para permitir a una entidad de IAM eliminar un rol vinculado a un servicio específico** agregue la siguiente instrucción a la política de permisos de la entidad de IAM entidad que necesita eliminar el rol vinculado con el servicio. ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*" } ``` **Para permitir a una entidad de IAM eliminar un rol vinculado a cualquier servicio** Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que necesita eliminar un rol vinculado con un servicio pero no una función de servicio. ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Para permitir que una entidad de IAM pase un rol existente al servicio** Algunos servicios de AWS le permiten pasar un rol existente en lugar de crear uno nuevo vinculado al servicio. Para ello, un usuario debe tener permisos para *pasar el rol* al servicio. Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que necesite pasar el rol. Esta instrucción de la política también permite a la entidad ver la lista de roles entre los que elegir el que se debe pasar. Para obtener más información, consulte [Conceder permisos a un usuario para transferir un rol a un servicio de AWS](id_roles_use_passrole.md). ``` { "Sid": "PolicyStatementToAllowUserToListRoles", "Effect": "Allow", "Action": ["iam:ListRoles"], "Resource": "*" }, { "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ" } ``` ## Permisos indirectos con funciones vinculadas al servicio Los permisos concedidos por un rol vinculado a un servicio se pueden transferir indirectamente a otros usuarios y roles. Cuando un rol vinculado al servicio es utilizado por un servicio de AWS, ese rol puede usar sus propios permisos para llamar a otros servicios de AWS. Esto significa que los usuarios y los roles con permisos para llamar a un servicio que usa un rol vinculado al servicio pueden tener acceso indirecto a los servicios a los que puede acceder dicho rol vinculado al servicio. Por ejemplo, al crear una instancia de base de datos de Amazon RDS, se crea automáticamente [un rol vinculado a un servicio para RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html) si aún no existe ninguno. Este rol vinculado al servicio permite a RDS llamar a Amazon EC2, Amazon SNS, Amazon CloudWatch Logs y Amazon Kinesis en su nombre siempre que edite la instancia de base de datos. Si se permite que los usuarios y los roles de su cuenta modifiquen o creen bases de datos de RDS, es posible que puedan interactuar indirectamente con los registros de Amazon EC2, Amazon SNS, los registros de Amazon CloudWatch y los recursos de Amazon Kinesis llamando a RDS, ya que RDS utilizaría su función vinculada al servicio para acceder a esos recursos. ### Métodos para crear un rol vinculado a un servicio El método que se utiliza para crear roles vinculados a servicios depende del servicio. En algunos casos, no es necesario crear manualmente roles vinculados a servicios. Por ejemplo, al finalizar una acción específica (por ejemplo, la creación de un recurso) en el servicio, este puede crear el rol vinculado al servicio en su nombre. Si utilizaba un servicio antes de que comenzara a admitir roles vinculados a servicios, el servicio podría crear automáticamente el rol en la cuenta. Para obtener más información, consulte [Un nuevo rol ha aparecido en la cuenta de AWS](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared). En otros casos, el servicio podría admitir la creación manual de un rol vinculado al servicio mismo mediante su consola, la API o la CLI. Para obtener información sobre los servicios que admiten el uso de roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md) y busque los servicios que tengan **Yes **en la columna **Service-Linked Role**. Para saber si el servicio admite la creación de roles vinculados al servicio mismo, haga clic en el enlace **Sí** para consultar la documentación relacionada con los roles vinculados a dicho servicio. Si el servicio no admite la creación de roles, puede utilizar IAM para crear el rol vinculado al servicio. **importante** Los roles vinculados a servicios se contabilizan como [roles de IAM en una Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities) pero, si ha alcanzado el límite de servicio, igualmente puede crear roles vinculados a servicios en su cuenta. Los roles vinculados a servicios son los únicos que pueden superar el límite. ### Creación de un rol vinculado a un servicio (consola) Antes de crear un rol vinculado a un servicio en IAM, averigüe primero si el servicio vinculado crea automáticamente roles vinculados a servicios, además aprenderá si es posible crearlo desde la consola del servicio, la API o la CLI. **Para crear un rol vinculado a un servicio (consola)** 1. Inicie sesión en la Consola de administración de AWS 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 consola de IAM, elija **Roles**. A continuación, elija **Create role** (Crear rol). 1. Elija el tipo de rol **Servicio de AWS**. 1. Elija el caso de uso para su servicio. Los casos de uso son definidos por el servicio de modo tal que ya incluyen la política de confianza exigida por el servicio mismo. A continuación, elija **Siguiente**. 1. Elija una o varias políticas de permisos para asociarlas al rol. En función del caso de uso seleccionado, el servicio podría realizar cualquiera de las siguientes acciones: + Definir los permisos que utiliza el rol. + Permitirle elegir permisos de un conjunto limitado. + Permitirle elegir cualquier permiso. + Permitirle no seleccionar ninguna política en ese momento, crear las políticas más adelante y, a continuación, asociarlas al rol. Seleccione la casilla situada junto a la política que asigna los permisos que desea que tenga el rol y, a continuación, elija **Siguiente**. **nota** Los permisos que especifique están disponibles para cualquier entidad que utilice el rol. De forma predeterminada, un rol no tiene permisos. 1. En **Role Name (Nombre del rol)**, el servicio define el grado de personalización del nombre del rol. Si el servicio define el nombre del rol, esta opción no es editable. En otros casos, el servicio puede definir un prefijo para el rol y permitirle ingresar un sufijo opcional. De ser posible, ingrese un sufijo de nombre de rol para agregarlo al nombre predeterminado. Este sufijo le permite identificar el propósito de este rol. Los nombres de rol deben ser únicos en su cuenta de AWS. No distinguen entre mayúsculas y minúsculas. Por ejemplo, no puede crear funciones denominado tanto **\$1SAMPLE** como **\$1sample**. Dado que varias entidades pueden hacer referencia al rol, no puede editar el nombre del rol después de crearlo. 1. (Opcional) En **Description** (Descripción), edite la descripción del nuevo rol vinculado al servicio. 1. No puede asociar etiquetas a roles vinculados a servicios durante la creación. 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. Revise el rol y, a continuación, seleccione **Crear rol**. ### Crear una función vinculada a un servicio (AWS CLI) Antes de crear un rol vinculado a un servicio en IAM, averigüe primero si el servicio vinculado crea automáticamente roles vinculados a servicios y si no es posible crearlo desde la CLI del servicio. Si la CLI del servicio no es compatible, puede utilizar comandos de IAM para crear un rol vinculado al servicio con la política de confianza y las políticas insertadas que el servicio necesita para asumir el rol. **Para crear un rol vinculado a un servicio (AWS CLI)** Use el siguiente comando: ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com ``` ### Crear un rol vinculado a un servicio (API de AWS) Antes de crear un rol vinculado a un servicio en IAM, averigüe primero si el servicio vinculado crea automáticamente roles vinculados a servicios y si no es posible crearlo desde la API del servicio. Si la API del servicio no es compatible, puede utilizar la API de AWS para crear un rol vinculado al servicio con la política de confianza y las políticas insertadas que el servicio necesita para asumir el rol. **Para crear un rol vinculado a un servicio (API de AWS)** Utilice la llamada a la API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). En la solicitud, especifique el nombre del servicio de `SERVICE_NAME_URL.amazonaws.com`. Por ejemplo, para crear el rol vinculado al servicio **Robots de Lex**, utilice `lex.amazonaws.com`. # Creación de un rol para un proveedor de identidad externo Puede utilizar proveedores de identidad en lugar de crear usuarios de IAM en una Cuenta de AWS. Con un proveedor de identidad (IdP), puede administrar las identidades de usuario fuera de AWS y conceder permisos a estas identidades de usuarios externos para que tengan acceso a los recursos de AWS de su cuenta. Para obtener más información acerca de la identidad federada y los proveedores de identidad, consulte [Proveedores de identidades y federación en AWS](id_roles_providers.md). ## Creación de un rol para entidades principales federadas de OIDC y SAML (consola) Los procedimientos para crear un rol dependen del proveedor externo que elija. + Para conexiones OpenID Connect (OIDC), consulte [Creación de un rol para una federación de OpenID Connect (consola)](id_roles_create_for-idp_oidc.md). + Para SAML 2.0, consulte [Creación de un rol para una federación SAML 2.0 (consola)](id_roles_create_for-idp_saml.md). ## Creación de un rol para acceso federado (AWS CLI) Los pasos que ha de seguir para crear un rol para los proveedores de identidad compatibles (OIDC o SAML) desde la AWS CLI son idénticos. La diferencia está en el contenido de la política de confianza que crea en los pasos de requisitos previos. Empiece siguiendo los pasos de la sección **Requisitos previos** para el tipo de proveedor que utilice: + Para un proveedor OIDC, consulte [Requisitos previos para crear un rol para OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites). + Para un proveedor SAML, consulte [Requisitos previos para crear un rol para SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites). Para crear un rol desde la AWS CLI se deben seguir varios pasos. Si utiliza la consola para crear un rol, muchos de los pasos se realizan automáticamente, pero con la AWS CLI deberá realizar cada paso usted mismo. Debe crear el rol y, a continuación, asignar una política de permisos al rol. Si lo prefiere, también puede configurar el [límite de permisos](access_policies_boundaries.md) para el rol. **Para crear un rol (AWS CLI)** 1. Crear un rol: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 1. Asociar una política de permisos al rol: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) o Crear una política de permisos insertada para el rol: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) 1. (Opcional) Añadir los atributos personalizados al rol asociando etiquetas: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Para obtener más información, consulte [Administrar etiquetas en roles de IAM (AWS CLI o API de AWS)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Opcional) Configurar el [límite de permisos](access_policies_boundaries.md) para el rol: [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. El siguiente ejemplo muestra los dos primeros pasos, que también son los más comunes, para crear un rol de proveedor de identidad en un entorno sencillo. Este ejemplo permite a cualquier usuario de la cuenta `123456789012` asumir el rol y ver el bucket de `example_bucket` Amazon S3. En el ejemplo, también se presupone que está ejecutando la AWS CLI en un equipo con Windows y que ya ha configurado la AWS CLI con sus credenciales. 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). En el ejemplo siguiente, la política de confianza está diseñada para una aplicación móvil si el usuario inicia sesión mediante Amazon Cognito. En este ejemplo, *us-east:12345678-ffff-ffff-ffff-123456* representa el ID del grupo de identidades asignado por Amazon Cognito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}} } } ``` ------ La siguiente política de permisos permite a cualquiera que asuma el rol realizar únicamente la acción `ListBucket` en el bucket de Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } } ``` ------ Para crear el rol `Test-Cognito-Role`, primero debe guardar la política de confianza anterior con el nombre `trustpolicyforcognitofederation.json` y la política de permisos anterior con el nombre `permspolicyforcognitofederation.json` en la carpeta `policies` del disco duro local `C:`. A continuación, puede utilizar los comandos siguientes para crear el rol y asociarle la política insertada. ``` # Create the role and attach the trust policy that enables users in an account to assume the role. $ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json # Attach the permissions policy to the role to specify what it is allowed to do. aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json ``` ## Creación de un rol para acceso federado (API de AWS) Los pasos que ha de seguir para crear un rol para los proveedores de identidad compatibles (OIDC o SAML) desde la AWS CLI son idénticos. La diferencia está en el contenido de la política de confianza que crea en los pasos de requisitos previos. Empiece siguiendo los pasos de la sección **Requisitos previos** para el tipo de proveedor que utilice: + Para un proveedor OIDC, consulte [Requisitos previos para crear un rol para OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites). + Para un proveedor SAML, consulte [Requisitos previos para crear un rol para SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites). **Para crear un rol (API AWS)** 1. Creación de un rol: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) 1. Asociar una política de permisos al rol: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) o Crear una política de permisos insertada para el rol: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) 1. (Opcional) Añadir los atributos personalizados al usuario asociando etiquetas: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Para obtener más información, consulte [Administrar etiquetas en usuarios de IAM (AWS CLI o API de AWS)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Opcional) Configuración del [límite de permisos](access_policies_boundaries.md) para el rol: [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Un límite de permisos controla los permisos que puede tener un rol como máximo. Los límites de permisos son una característica avanzada de AWS. # Creación de un rol para una federación de OpenID Connect (consola) Puede utilizar proveedores de identidad federados de OpenID Connect (OIDC) en lugar de crear usuarios de AWS Identity and Access Management en la Cuenta de AWS. Con un proveedor de identidad (IdP), puede administrar las identidades de usuario fuera de AWS y conceder permisos a estas identidades de usuarios externos para que tengan acceso a los recursos de AWS de su cuenta. Para obtener más información acerca de la federación y los IdP, consulte [Proveedores de identidades y federación en AWS](id_roles_providers.md). ## Requisitos previos para crear un rol para OIDC Para poder crear un rol para federación de OIDC, antes debe completar los siguientes pasos de los requisitos previos. **Preparativos para crear un rol para la federación de OIDC** 1. Regístrese con uno o más servicios que ofrezcan identidad de OIDC federada. Si está creando una aplicación que necesita obtener acceso a los recursos de AWS, también deberá configurarla con la información del proveedor. Cuando lo haga, el proveedor le proporcionará un ID de aplicación o de público exclusivo de la aplicación. (Cada proveedor utiliza una terminología diferente para este proceso. En esta guía se utiliza el término *configurar* para el proceso de identificación de su aplicación con el proveedor). Puede configurar varias aplicaciones con cada proveedor o varios proveedores con una sola aplicación. Consulte la información sobre el uso de los proveedores de identidades de la siguiente manera: + [Registro con Amazon Developer Center](https://login.amazon.com/) + [Añada inicio de sesión con Facebook a su aplicación o sitio web](https://developers.facebook.com/docs/facebook-login/v2.1) en el sitio de desarrolladores de Facebook. + [Uso de OAuth 2.0 para iniciar sesión (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login) en el sitio de desarrolladores de Google. 1. Después de recibir la información necesaria del IdP, cree un IdP en IAM. Para obtener más información, consulte [Crear un proveedor de identidad de IAM OpenID Connect (OIDC)](id_roles_providers_create_oidc.md). **importante** Si utiliza un IdP de OIDC de Google, Facebook o Amazon Cognito, no cree un IdP de IAM independiente en el Consola de administración de AWS. Estos proveedores de identidades de OIDC ya están integrados en AWS y están disponibles para su uso. Omita este paso y cree nuevos roles con su IdP en el siguiente paso. 1. Prepare las políticas para el rol que asumirán los usuarios autenticados mediante el proveedor de identidades. Como sucede con cualquier otro rol, un rol para una aplicación móvil incluye dos políticas. Una es la política de confianza que especifica quién puede asumir el rol. La otra es la política de permisos que especifica las acciones y los recursos de AWS a los que la aplicación móvil puede obtener acceso o se le deniega. En el caso de IdP web, le recomendamos utilizar [Amazon Cognito](https://aws.amazon.com/cognito/) para administrar las identidades. En este caso, utilice una política de confianza similar a la de este ejemplo. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"}, "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"} } } } ``` ------ Reemplace `us-east-2:12345678-abcd-abcd-abcd-123456` por el ID del grupo de identidades que Amazon Cognito le ha asignado. Si configura de manera manual un proveedor de identidad OIDC (IdP), al crear la política de confianza debe utilizar tres valores que garanticen que únicamente su aplicación puede asumir el rol: + En el elemento `Action`, utilice la acción `sts:AssumeRoleWithWebIdentity`. + En el elemento `Principal`, utilice la cadena `{"Federated":providerUrl/providerArn}`. + En el caso de algunos IdP de OIDC conocidos, el `providerUrl` es una URL. En los siguientes ejemplos se incluyen métodos que permiten especificar la entidad principal para algunos de estos proveedores de identidad: `"Principal":{"Federated":"cognito-identity.amazonaws.com"}` `"Principal":{"Federated":"www.amazon.com"}` `"Principal":{"Federated":"graph.facebook.com"}` `"Principal":{"Federated":"accounts.google.com"}` + Para los demás proveedores de OIDC, utilice el nombre de recurso de Amazon (ARN) del proveedor de identidades de OIDC que ha creado en [Step 2](#idpoidcstep2), como se muestra en el siguiente ejemplo: `"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}` + En el elemento `Condition`, utilice una condición `StringEquals` para limitar los permisos. Pruebe el ID del grupo de identidades (para Amazon Cognito) o el ID de aplicación (para otros proveedores). El ID del grupo de identidades debe coincidir con el ID de la aplicación que ha recibido al configurarla con el IdP. Esta coincidencia entre los ID asegura que la solicitud provenga de su aplicación. **nota** Los roles de IAM para los grupos de identidades de Amazon Cognito confían en que la entidad principal `cognito-identity.amazonaws.com` del servicio asuma el rol. Los roles de este tipo deben contener al menos una clave de condición para limitar el número de entidades principales que pueden asumir el rol. Se aplican consideraciones adicionales a los grupos de identidades de Amazon Cognito que asumen [roles de IAM entre cuentas](access_policies-cross-account-resource-access.md). Las políticas de confianza de estos roles deben aceptar la entidad principal del servicio `cognito-identity.amazonaws.com` y deben contener la clave de condición `aud` para restringir la asunción de roles a los usuarios de los grupos de identidades previstos. Una política que confíe en los grupos de identidades de Amazon Cognito sin esta condición crea el riesgo de que un usuario de un grupo de identidades no deseado asuma el rol. Para obtener más información, consulte [Políticas de confianza para roles de IAM en la autenticación básica (clásica)](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies) en la *Guía para desarrolladores de Amazon Cognito*. Cree un elemento de condición similar a uno de los siguientes ejemplos, en función del IdP que esté utilizando: `"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}` `"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}` `"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}` `"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}` En el caso de los proveedores OIDC, utilice la dirección URL completa del proveedor de identidad OIDC con la clave de contexto `aud`, como se muestra en el siguiente ejemplo: `"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}` **nota** Observe que los valores de la entidad principal de la política de confianza del rol son específicos de un IdP. Un rol para OIDC puede especificar solo una entidad principal. Por lo tanto, si la aplicación móvil permite a los usuarios iniciar sesión desde varios IdP, debe crear un rol independiente para cada IdP que desee admitir. Cree políticas de confianza independientes para cada IdP. Si un usuario utiliza una aplicación móvil para iniciar sesión desde Inicio de sesión con Amazon, se aplicará el siguiente ejemplo de política de confianza. En el ejemplo, *amzn1.application-oa2-123456* representa el ID de la aplicación que Amazon asignó cuando configuró la aplicación con Login with Amazon. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForLoginWithAmazon", "Effect": "Allow", "Principal": {"Federated": "www.amazon.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}} }] } ``` ------ Si un usuario utiliza una aplicación móvil para iniciar sesión desde Facebook, se aplicará el siguiente ejemplo de política de confianza. En este ejemplo, *111222333444555* representa el ID de la aplicación asignado por Facebook. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForFacebook", "Effect": "Allow", "Principal": {"Federated": "graph.facebook.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}} }] } ``` ------ Si un usuario utiliza una aplicación móvil para iniciar sesión desde Google, se aplicará el siguiente ejemplo de política de confianza. En este ejemplo, *666777888999000* representa el ID de la aplicación asignado por Google. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForGoogle", "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}} }] } ``` ------ Si un usuario utiliza una aplicación móvil para iniciar sesión desde Amazon Cognito, se aplicará el siguiente ejemplo de política de confianza. En este ejemplo, *us-east:12345678-ffff-ffff-ffff-123456* representa el ID del grupo de identidades asignado por Amazon Cognito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}} }] } ``` ------ ## Creación de un rol para OIDC Después de completar los requisitos previos, puede crear el rol en IAM. Para los proveedores de identidades compartidos de OpenID Connect (OIDC) reconocidos, IAM exige la evaluación explícita de ciertas declaraciones en los JSON Web Tokens (JWT), lo que se conoce como *controles del proveedor de identidades*. Para obtener más información sobre qué proveedores de identidades OIDC tienen *controles de proveedor de identidades*, consulte [Controles del proveedor de identidad para proveedores compartidos de OIDC](id_roles_providers_oidc_secure-by-default.md). En el siguiente procedimiento se describe cómo crear el rol de federación de OIDC en la Consola de administración de AWS. Para crear un rol desde la AWS CLI o la API de AWS, consulte los procedimientos en [Creación de un rol para un proveedor de identidad externo](id_roles_create_for-idp.md). **importante** Si utiliza Amazon Cognito, debe utilizar la consola de Amazon Cognito para configurar los roles. De lo contrario, utilice la consola de IAM para crear un rol para la federación de OIDC. **Cómo crear un rol de IAM para una federación de OIDC** 1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación, seleccione **Roles** y, a continuación, seleccione **Crear rol**. 1. Elija **Identidad web** como tipo de entidad de confianza y seleccione **Siguiente**. 1. En **Proveedor de identidad**, elija el IdP para el rol: + Si está creando un rol para un IdP web individual, elija **Inicio de sesión con Amazon**, **Facebook** o **Google**. **nota** Debe crear un rol independiente para cada IdP al que desee admitir. + Si está creando un rol de situación avanzada para Amazon Cognito, elija **Amazon Cognito**. **nota** Solo deberá crear manualmente un rol para utilizarlo con Amazon Cognito si está trabajando en una situación avanzada. En caso contrario, Amazon Cognito puede crear roles de forma automática. Para obtener más información sobre Amazon Cognito, consulte [Proveedores de identidades externos de grupos de identidad (identidades federadas)](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) en la *Guía para desarrolladores de Amazon Cognito*. + Si quiere crear un rol para GitHub Actions, primero debe agregar el proveedor OIDC de GitHub a IAM. Después de agregar el proveedor OIDC de GitHub a IAM, elija **token.actions.githubusercontent.com**. **nota** Para obtener información acerca de cómo configurar AWS para confiar en el proveedor de OIDC de GitHub como una identidad federada, consulte [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Para obtener información sobre las mejores prácticas para limitar el acceso a los roles asociados al IdP de IAM para GitHub, consulte [Configuración de un rol para el proveedor de identidades de OIDC de GitHub](#idp_oidc_Create_GitHub) en esta página. + Si quiere crear un rol para HashiCorp Cloud Platform (HCP) Terraform, primero debe añadir el proveedor de OIDC de Terraform a IAM. Después de añadir el proveedor de OIDC de Terraform a IAM, elija **app.terraform.io**. **importante** Los roles de IAM para el proveedor de OIDC de HashiCorp Cloud Platform (HCP) Terraform debe evaluar la clave de condición de IAM, `app.terraform.io:sub`, en la política de confianza de funciones. Esta clave de condición limita los roles que las organizaciones, los proyectos, los espacios de trabajo o las fases de ejecución de Terraform de HCP pueden asumir. Sin esta clave de condición, su política de confianza permite que personas ajenas a la organización accedan a su rol y a sus recursos de AWS, lo que no se ajusta al principio del privilegio mínimo. Si establece o modifica una política de confianza de roles para un rol asociado al proveedor de OIDC de HCP Terraform en su cuenta de AWS, pero no evalúa la clave de condición de IAM `app.terraform.io:sub`, recibirá un error. Además, AWS STS denegará las solicitudes de autorización si su política de confianza de roles no evalúa esta clave de condición. 1. La información solicitada varía según el proveedor OIDC que elija. + Ingrese el identificador de su aplicación. La etiqueta del identificador cambia en función del proveedor que elija: + Si está creando un rol para Inicio de sesión con Amazon, ingrese el ID de la aplicación en el cuadro **ID de aplicación**. + Si está creando un rol para Facebook, ingrese el ID de la aplicación en el cuadro **ID de aplicación**. + Si está creando un rol para Google, ingrese el nombre de los destinatarios en el cuadro **Público**. + Si está creando un rol para Amazon Cognito, ingrese el ID del grupo de identidades que ha creado para sus aplicaciones de Amazon Cognito en el campo **ID de grupo de identidades**. + Si quiere crear un rol para GitHub Actions, introduzca los siguientes detalles: + En **Público**, elija `sts.amazonaws.com`. + Para **Organización de GitHub**, introduzca el nombre de la organización de GitHub. El nombre de la organización de GitHub es obligatorio y debe ser alfanumérico, incluyendo guiones (-). No se pueden usar caracteres comodín (\$1 y ?) en el nombre de la organización de GitHub. + (Opcional) Para el **repositorio GitHub**, introduzca el nombre del repositorio GitHub. Si no especifica un valor, se utilizará por defecto un comodín (`*`). + (Opcional) Para la **ramificación GitHub**, introduzca el nombre de la ramificación GitHub. Si no especifica un valor, se utilizará por defecto un comodín (`*`). + Si quiere crear un rol para HashiCorp Cloud Platform (HCP) Terraform, introduzca los siguientes detalles: + En **Público**, elija `aws.workload.identity`. + En **Organización**, introduzca el nombre de la organización. Puede especificar un carácter comodín (`*`) para todas las organizaciones. + En **Proyecto**, introduzca el nombre del proyecto. Puede especificar un carácter comodín (`*`) para todos los proyectos. + En **Espacio de trabajo**, introduzca un nombre del espacio de trabajo. Puede especificar un carácter comodín (`*`) para todos los espacios de trabajo. + En **Fase de ejecución**, introduzca el nombre de la fase de ejecución. Puede especificar un carácter comodín (`*`) para todas las fases de ejecución. 1. (Opcional) Para **Condición (opcional)**, elija **Añadir condición** para crear condiciones adicionales que deben cumplirse antes de que los usuarios de su aplicación puedan utilizar los permisos que el rol les concede. Por ejemplo, puede agregar una condición que conceda acceso a recursos de AWS únicamente a un ID de usuario de IAM concreto. También puede añadir condiciones a la política de confianza después de crear el rol. Para obtener más información, consulte [Actualizar una política de confianza de rol](id_roles_update-role-trust-policy.md). 1. Revise la información de OIDC y, a continuación, seleccione **Siguiente**. 1. IAM incluye una lista de las políticas administradas por AWS y de las políticas administradas por el cliente en su cuenta. Seleccione la política que desea utilizar como política de permisos o elija **Crear Política** para abrir una pestaña nueva del navegador y crear una política nueva desde cero. Para obtener más información, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start). Después de crear la política, cierre esa pestaña y vuelva a la pestaña original. Seleccione la casilla de verificación situada junto a las políticas de permisos que desea conceder a los usuarios de OIDC. Si lo prefiere, puede optar por no seleccionar ninguna política en este momento y asociar las políticas al rol más adelante. De forma predeterminada, un rol no tiene permisos. 1. (Opcional) Configure un [límite de permisos](access_policies_boundaries.md). Esta es una característica avanzada. Abra la sección **Limites de permisos** y elija **Utilizar un límite de permisos para controlar los permisos que puede tener el rol como máximo).** Seleccione la política que desea utilizar para el límite de permisos. 1. Elija **Siguiente**. 1. En **Nombre de rol**, ingrese un nombre de rol. Los nombres de rol deben ser únicos en su Cuenta de AWS. No dependen de los casos. Por ejemplo, no puede crear funciones denominadas tanto **PRODROLE** como **prodrole**. Dado que es posible que otros recursos de AWS hagan referencia al rol, no se puede editar el nombre del rol después de crearlo. 1. (Opcional) En **Descripción**, ingrese una descripción para el nuevo rol. 1. Para editar los casos de uso y los permisos del rol, elija **Editar** en las secciones **(Paso 1: seleccionar entidades de confianza)** o **(Paso 2: agregar permisos).** 1. (Opcional) Para agregar metadatos al rol, asocie etiquetas como pares 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. Revise el rol y, a continuación, seleccione **Crear rol**. ## Configuración de un rol para el proveedor de identidades de OIDC de GitHub Si usa GitHub como un proveedor de identidades (IdP) de OIDC, la práctica recomendada es limitar las entidades que pueden asumir el rol asociado con el IdP de IAM. Cuando incluye una declaración de condición en la política de confianza, puede limitar el rol a una organización, un repositorio o una rama de GitHub específica. Puede usar la clave de condición `token.actions.githubusercontent.com:sub` con operadores de condición de cadena para limitar el acceso. Recomendamos limitar la condición a un conjunto específico de repositorios o ramas dentro de la organización GitHub. Para obtener información acerca de cómo configurar AWS para confiar en el OIDC de GitHub como una identidad federada, consulte [GitHub Docs: configuración de OpenID Connect en Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Si utiliza los entornos de GitHub en los flujos de trabajo de acción o en las políticas de OIDC, recomendamos agregar reglas de protección al entorno para una mayor seguridad. Utilice las ramas y las etiquetas de implementación para restringir qué ramas y etiquetas se pueden implementar en el entorno. Para más información sobre la configuración de entornos con reglas de protección, consulte [Ramas y etiquetas de implementación](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags) en el artículo *Uso de entornos para la implementación* de GitHub. Cuando el IdP OIDC de GitHub es la entidad principal de confianza para su rol, IAM comprueba la condición de la política de confianza del rol para verificar que la clave de condición `token.actions.githubusercontent.com:sub` está presente y su valor no es únicamente un carácter comodín (\$1 y ?) o nulo. IAM realiza esta comprobación cuando se crea o actualiza la política de confianza. Si la clave de condición `token.actions.githubusercontent.com:sub` no está presente o el valor de la clave no cumple los criterios de valor mencionados, la solicitud fallará y devolverá un error. **importante** Si no limita la clave de condición `token.actions.githubusercontent.com:sub` a una organización o repositorio específicos, GitHub Actions de organizaciones o repositorios fuera de su control pueden asumir roles asociados con el IdP de IAM de GitHub en su cuenta de AWS. En el siguiente ejemplo de política de confianza se limita el acceso a la organización, el repositorio y la rama de GitHub definidos. El valor de la clave de condición `token.actions.githubusercontent.com:sub` del siguiente ejemplo es el formato de valor del asunto predeterminado documentado por GitHub. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch" } } } ] } ``` ------ La siguiente condición de ejemplo limita el acceso a la organización y el repositorio de GitHub definidos, pero otorga acceso a cualquier rama del repositorio. ``` "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*" } } ``` La siguiente condición de ejemplo limita el acceso a cualquier rama o repositorio de la organización de GitHub definida. Recomendamos limitar la clave de condición `token.actions.githubusercontent.com:sub` a un valor específico que limite el acceso a GitHub Actions desde dentro de la organización de GitHub. ``` "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*" } } ``` Para obtener más información sobre las claves de federación de OIDC disponibles para verificaciones de condición en las políticas, consulte [Claves disponibles para las federaciones de identidades AWS de OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif). # Creación de un rol para una federación SAML 2.0 (consola) Puede utilizar la federación SAML 2.0 en lugar de crear usuarios de IAM en una Cuenta de AWS. Con un proveedor de identidad (IdP), puede administrar las identidades de usuario fuera de AWS y conceder permisos a estas identidades de usuarios externos para que tengan acceso a los recursos de AWS de su cuenta. Para obtener más información acerca de la identidad federada y los proveedores de identidad, consulte [Proveedores de identidades y federación en AWS](id_roles_providers.md). **nota** Para mejorar la resiliencia de la federación, le recomendamos que configure su IdP y su federación de AWS para que admitan varios puntos de conexión de inicio de sesión de SAML. Para obtener más información, consulte el artículo del blog sobre seguridad de AWS, [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover). ## Requisitos previos para crear un rol para SAML Para poder crear un rol de federación de SAML 2.0, antes debe completar los siguientes pasos de requisitos previos. **Preparativos para crear un rol para la federación SAML 2.0** 1. Para poder crear un rol para una federación basada en SAML, debe crear un proveedor de SAML en IAM. Para obtener más información, consulte [Crear un proveedor de identidades de SAML en IAM](id_roles_providers_create_saml.md). 1. Prepare las políticas del rol que los usuarios autenticados por SAML 2.0 asumirán. Al igual que ocurre con cualquier otro rol, un rol para la federación SAML incluye dos políticas. Una es la política de confianza de rol que especifica quién puede asumir el rol. La otra es la política de permisos de IAM que define las acciones de AWS y los recursos a los que la entidad principal federada mediante SAML puede acceder o tiene denegado el acceso. Al crear la política de confianza para el rol, debe utilizar tres valores que garantizan que solo la aplicación pueda asumir el rol: + En el elemento `Action`, utilice la acción `sts:AssumeRoleWithSAML`. + En el elemento `Principal`, utilice la cadena `{"Federated":ARNofIdentityProvider}`. Sustituya `ARNofIdentityProvider` por el ARN del [proveedor de identidad SAML](id_roles_providers_saml.md) que ha creado en [Step 1](#idpsamlstep1). + En el elemento `Condition`, utilice una condición `StringEquals` para probar que el atributo `saml:aud` de la respuesta de SAML coincida con la URL que muestra el navegador al iniciar sesión en la consola. Esta URL de punto de conexión de inicio de sesión es el atributo del destinatario de SAML del proveedor de identidades. Puede incluir URL de inicio de sesión en determinadas regiones. AWS recomienda usar los puntos de conexión regionales en lugar del punto de conexión global para mejorar la resiliencia de la federación. Para obtener una lista de los posibles valores de *region-code*, consulte la columna **Region** (Región) en [Puntos de conexión de inicio de sesión de AWS](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Si se requiere el cifrado de SAML, la URL de inicio de sesión debe incluir el identificador único que AWS asigna al proveedor de SAML. Para ver el identificador único, seleccione el proveedor de identidades en la consola de IAM para que aparezca la página de detalles. `https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID` La política de confianza del ejemplo siguiente está diseñada para un usuario federado de SAML: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRoleWithSAML", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME" }, "Condition": { "StringEquals": { "SAML:aud": "https://region-code.signin.aws.amazon.com/saml" } } } } ``` ------ Sustituya el ARN de la entidad principal por el ARN real del proveedor SAML que ha creado en IAM. Tendrá su ID de cuenta y su nombre de proveedor. ## Creación de un rol para SAML Después de completar los pasos de los requisitos previos, puede a crear el rol para la federación basada en SAML. **Para crear un rol para la federación basada en SAML** 1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la consola de IAM, elija **Roles** y, a continuación, elija **Crear rol**. 1. Elija el tipo de rol **SAML 2.0 federation**. 1. En **Select a SAML provider** (Seleccionar un proveedor de SAML), elija el proveedor para el rol. 1. Elija el método de nivel de acceso SAML 2.0. + Elija **Allow programmatic access only (Permitir solo acceso mediante programación)** para crear un rol que se pueda asumir mediante programación desde la API o la AWS CLI de AWS. + Elija **Permitir el acceso Consola de administración de AWS mediante la consola y mediante programación** para crear un rol que pueda ser asumido mediante programación y desde la Consola de administración de AWS. Los roles creados con ambas opciones son similares, pero el rol que puede ser asumido desde la consola incluye una política de confianza con una condición particular. Dicha condición garantiza explícitamente que el público de SAML (atributo `SAML:aud`) esté establecido en el punto de conexión de inicio de sesión de AWS para el proveedor de SAML. 1. El procedimiento para definir los atributos varía según el tipo de acceso. + Si está creando un rol para el acceso mediante programación, elija un atributo en la lista **Attribute (Atributo)**. A continuación, en el cuadro **Value** (Valor), ingrese un valor para incluirlo en el rol. Esto restringe el acceso del rol a los usuarios del proveedor de identidad cuya respuesta de autenticación SAML (aserción) incluya los atributos que especifique. Debe especificar al menos un atributo para garantiza que el rol esté limitado a un subconjunto de usuarios de su organización. + Si está creando un rol para el acceso mediante programación y a la Consola de administración de AWS, la sección **Puntos de conexión de inicio de sesión** define la URL que muestra el navegador al iniciar sesión en la consola. Este punto de conexión es el atributo de destinatario de SAML del proveedor de identidades, que se asigna a la clave de contexto [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml). Para obtener más información, consulte [Configure aserciones SAML para la respuesta de autenticación](id_roles_providers_create_saml_assertions.md). 1. Elija **Puntos de conexión regionales** o **Puntos de conexión no regionales**. Recomendamos utilizar varios puntos de conexión de inicio de sesión de SAML regionales para mejorar la resiliencia de la federación. 1. En **Regiones**, elija las regiones que admita el proveedor de SAML para el inicio de sesión de AWS. 1. En **URL de inicio de sesión para incluir identificadores únicos**, seleccione si los puntos de conexión de inicio de sesión incluyen identificadores únicos que AWS asigna al proveedor de identidades de SAML. Esta opción es obligatoria para las aserciones de SAML cifradas. Para obtener más información, consulte [Federación SAML 2.0](id_roles_providers_saml.md). 1. Para agregar más condiciones relacionadas con el atributo a la política de confianza, elija **Condition (optional)** (Condición [opcional]), seleccione la condición adicional y especifique un valor. **nota** La lista incluye los atributos SAML utilizados con más frecuencia. IAM admite atributos adicionales que puede utilizar para crear condiciones. Para ver una lista de los atributos admitidos, consulte [Claves disponibles para federaciones SAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml). Si necesita una condición para un atributo SAML admitido que no se muestra en la lista, puede añadir manualmente dicha condición. Para ello, edite la política de confianza después de crear el rol. 1. Revise la información de confianza de SAML 2.0 y, a continuación, elija **Next** (Siguiente). 1. IAM incluye una lista de las políticas administradas por AWS y de las políticas administradas por el cliente en su cuenta. Seleccione la política que desea utilizar como política de permisos o elija **Crear Política** para abrir una pestaña nueva del navegador y crear una política nueva desde cero. Para obtener más información, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start). Después de crear la política, cierre esa pestaña y vuelva a la pestaña original. Seleccione la casilla situada junto a las políticas de permisos que desea otorgar a los usuarios federados de SAML. Si lo prefiere, puede optar por no seleccionar ninguna política en este momento y asociar las políticas al rol más adelante. De forma predeterminada, un rol no tiene permisos. 1. (Opcional) Configure un [límite de permisos](access_policies_boundaries.md). Esta es una característica avanzada. Abra la sección **Limites de permisos** y elija **Utilizar un límite de permisos para controlar los permisos que puede tener el rol como máximo).** Seleccione la política que desea utilizar para el límite de permisos. 1. Elija **Siguiente**. 1. Elija **Siguiente: Revisar**. 1. En **Nombre de rol**, ingrese un nombre de rol. Los nombres de rol deben ser únicos en su Cuenta de AWS. No distinguen entre mayúsculas y minúsculas. Por ejemplo, no puede crear funciones denominado tanto **PRODROLE** como **prodrole**. Dado que es posible que otros recursos de AWS hagan referencia al rol, no se puede editar el nombre del rol después de crearlo. 1. (Opcional) En **Description** (Descripción), ingrese una descripción para el nuevo rol. 1. Elija **Edit** (Editar) en las secciones **Step 1: Select trusted entities** (Paso 1: seleccionar entidades de confianza) o **Step 2: Add permissions** (Paso 2: agregar permisos) para editar los casos de uso y los permisos del rol. 1. De manera opcional, agregue metadatos al rol asociando 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. Revise el rol y, a continuación, seleccione **Crear rol**. Después de crear el rol, complete la relación de confianza de SAML configurando su software de proveedor de identidad con información sobre AWS. Esta información incluye los roles que desea que utilicen los usuarios federados de SAML. Esto se denomina configuración de la relación de confianza entre su proveedor de identidad y AWS. Para obtener más información, consulte [Configuración su SAML 2.0 IdP con una relación de confianza para usuario autenticado y agregando reclamos](id_roles_providers_create_saml_relying-party.md). # Crear un rol mediante políticas de confianza personalizadas Puede crear una política de confianza personalizada para delegar el acceso y permitir que otros realicen acciones en su Cuenta de AWS. Para obtener más información, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start). Para obtener información sobre cómo utilizar los roles para delegar permisos, consulte [Términos y conceptos de roles](id_roles.md#id_roles_terms-and-concepts). ## Creación de un rol de IAM mediante políticas de confianza personalizadas (consola) Puede utilizar la Consola de administración de AWS para crear un rol que un usuario de IAM pueda asumir. Por ejemplo, suponga que su organización tiene varias Cuentas de AWS para aislar un entorno de desarrollo de uno de producción. Para información general sobre cómo crear un rol que permita a usuarios de la cuenta de desarrollo acceder a los recursos de la cuenta de producción, consulte [Situación de ejemplo en la que se usan cuentas de desarrollo y producción separadas](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example). **Para crear un rol mediante políticas de confianza personalizadas (consola)** 1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la consola, elija **Roles** y, a continuación, seleccione **Crear rol**. 1. Elija el tipo de rol **Custom trust policy** (Política de confianza personalizada). 1. En la sección **Custom trust policy** (Política de confianza personalizada), ingrese o pegue la política de confianza personalizada para el rol. Para obtener más información, consulte [Crear políticas de IAM](access_policies_create-console.md#access_policies_create-start). 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 **Next**. 1. (Opcional) Configure un [límite de permisos](access_policies_boundaries.md). Se trata de una característica avanzada que está disponible para los roles de servicio, pero no para los roles vinculados a servicios. Abra la sección **Permissions boundary** (Límite de permisos) y elija **Use a permissions boundary to control the maximum role permissions** (Utilizar un límite de permisos para controlar los permisos que puede tener el rol como máximo). IAM incluye una lista de las políticas administradas por AWS y de las políticas administradas por el cliente en su cuenta. Seleccione la política que desea utilizar para el límite de permisos. 1. Elija **Siguiente**. 1. En **Role Name (Nombre del rol)**, el servicio define el grado de personalización del nombre del rol. Si el servicio define el nombre del rol, esta opción no es editable. En otros casos, el servicio puede definir un prefijo para el rol y permitirle escribir un sufijo opcional. Algunos servicios le permiten especificar el nombre completo de su rol. Si es posible, ingrese un nombre de rol o un sufijo de nombre de rol. Los nombres de rol deben ser únicos en su Cuenta de AWS. No distinguen entre mayúsculas y minúsculas. Por ejemplo, no puede crear funciones denominado tanto **PRODROLE** como **prodrole**. Dado que es posible que otros recursos de AWS hagan referencia al rol, no se puede editar el nombre del rol después de crearlo. 1. (Opcional) En **Description** (Descripción), ingrese una descripción para el nuevo rol. 1. (Opcional) Seleccione **Editar** en las secciones **Paso 1: seleccionar entidades de confianza** o **Paso 2: agregar permisos** para modificar la política personalizada y los permisos del rol. 1. De manera opcional, agregue metadatos al rol asociando 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. Revise el rol y, a continuación, seleccione **Crear rol**. # Ejemplos de políticas para delegar el acceso En los siguientes ejemplos se muestra cómo puede permitir o conceder acceso a una Cuenta de AWS a los recursos de otra Cuenta de AWS. Para obtener información sobre cómo crear una política de IAM mediante estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas mediante el editor JSON](access_policies_create-console.md#access_policies_create-json-editor). **Topics** + [ ## Uso de roles para delegar el acceso a otros recursos de la Cuenta de AWS ](#example-delegate-xaccount-rolesapi) + [ ## Uso de una política para delegar el acceso a los servicios ](#id_roles_create_policy-examples-access-to-services) + [ ## Uso de una política basada en recursos para delegar el acceso a un bucket de Amazon S3 de otra cuenta ](#example-delegate-xaccount-S3) + [ ## Uso de una política basada en recursos para delegar el acceso a una cola de Amazon SQS de otra cuenta ](#example-delegate-xaccount-SQS) + [ ## No se puede delegar el acceso cuando la cuenta tiene el acceso denegado ](#example-delegate-xaccount-SQS-denied) ## Uso de roles para delegar el acceso a otros recursos de la Cuenta de AWS Para ver un tutorial que muestra cómo utilizar los roles de IAM para conceder a los usuarios de una cuenta acceso a los recursos de AWS que se encuentran en otra cuenta, consulte [Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM](tutorial_cross-account-with-roles.md). **importante** Puede incluir el ARN de un rol o usuario específico en el elemento `Principal` de una política de confianza de rol. Al guardar la política, AWS transforma el ARN a un ID exclusivo de entidad principal. Esto ayuda a mitigar el riesgo de que alguien aumente sus privilegios eliminando o volviendo a crear el rol o usuario. Normalmente este ID no se muestra en la consola, ya que también existe una transformación inversa al ARN cuando se muestra la política de confianza. Sin embargo, si elimina el rol o el usuario, la relación se desvincula. La política ya no se aplica, incluso si vuelva a crear el usuario o rol, ya que no coincide con el ID principal almacenado en la política de confianza. Cuando esto sucede, el ID principal se muestra en la consola, ya que AWS no puede volver a asignarlo a un ARN. El resultado es que si elimina y vuelve a crear un usuario o rol al que se hace referencia en un elemento `Principal` de la política de confianza, debe editar el rol para sustituir el ARN. Se transforma en el nuevo ID de entidad principal al guardar la política. ## Uso de una política para delegar el acceso a los servicios En el siguiente ejemplo se muestra una política que puede asociarse a un rol. La política permite que dos servicios, Amazon EMR y AWS Data Pipeline asuman el rol. Los servicios pueden realizar las tareas concedidas por la política de permisos asignada al rol (no se muestra). Para especificar varios elementos principales del servicio, no debe especificar dos elementos `Service`; solo puede tener uno. En cambio, utilice una gama de varios elementos principales del servicio como el valor de un único elemento `Service`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "elasticmapreduce.amazonaws.com", "datapipeline.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ ## Uso de una política basada en recursos para delegar el acceso a un bucket de Amazon S3 de otra cuenta En este ejemplo, la cuenta A utiliza una política basada en recursos (una [política de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html) de Amazon S3) para conceder a la cuenta B acceso completo al bucket de S3 de la cuenta A. A continuación, la cuenta B crea una política de usuario de IAM para delegar el acceso del bucket de la cuenta A a uno de los usuarios de la cuenta B. La política de bucket de S3 de la cuenta A podría ser como la siguiente política. En este ejemplo, el bucket de S3 de la cuenta A se llama *amzn-s3-demo-bucket*, mientras que el número de cuenta de la cuenta B es 111122223333. No se especifica los usuarios individuales ni grupos de la cuenta B, solo la cuenta. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "AccountBAccess1", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } } ``` ------ De forma alternativa, la cuenta A puede utilizar las [Listas de control de acceso (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) de Amazon S3 para conceder a la cuenta B acceso a un bucket de S3 o a un único objeto de un bucket. En tal caso, lo único que cambia es cómo la cuenta A concede acceso a la cuenta B. La cuenta B todavía utiliza una política para delegar el acceso a un grupo de IAM de la cuenta B, tal y como se describe en la próxima sección de este ejemplo. Para obtener más información sobre el control del acceso a los buckets y objetos de S3, vaya a [Control de acceso](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) en la *Guía del usuario de Amazon Simple Storage Service*. El administrador de la cuenta B puede crear la siguiente muestra de política. La política permite el acceso de lectura a un grupo o usuario de la cuenta B. La política anterior concede acceso a la cuenta B. Sin embargo, los grupos y usuarios individuales de la cuenta B no pueden obtener acceso al recurso hasta que una política de grupo o usuario conceda de forma explícita los permisos al recurso. Los permisos de esta política solo pueden ser un subconjunto de los de la anterior política entre cuentas. La cuenta B no puede conceder más permisos a sus grupos y usuarios que los que la cuenta A concedió a la cuenta B en la primera política. En esta política, el elemento `Action` se define de forma explícita para permitir únicamente acciones `List` y el elemento `Resource` de esta política coincide con `Resource` para la política de bucket implementada por la cuenta A. Para aplicar esta política, la cuenta B utiliza IAM para asociarla al usuario adecuado (o grupo) de la cuenta B. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:List*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } } ``` ------ ## Uso de una política basada en recursos para delegar el acceso a una cola de Amazon SQS de otra cuenta En el siguiente ejemplo, la cuenta A tiene una cola de Amazon SQS que utiliza una política basada en recursos asociados a la cola para conceder acceso a la cola a la cuenta B. A continuación, la cuenta B utiliza una política de grupo de IAM para delegar el acceso a un grupo de la cuenta B. En el siguiente ejemplo una política de cola concede permiso a la cuenta B para realizar las acciones `SendMessage` y `ReceiveMessage` en la cola de la cuenta A denominada *queue1*, pero solo entre las 12:00 h y las 15:00 h del 30 de noviembre de 2014. El número de la cuenta B es 1111-2222-3333. La cuenta A utiliza Amazon SQS para implementar esta política. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": ["arn:aws:sqs:*:123456789012:queue1"], "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"}, "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"} } } } ``` ------ La política de la cuenta B para delegar el acceso a un grupo de la cuenta B podría ser como el siguiente ejemplo. La cuenta B utiliza IAM para asociar esta política a un grupo (o usuario). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:queue1" } } ``` ------ En el ejemplo anterior de la política de usuario de IAM, la cuenta B utiliza un carácter comodín para conceder acceso a su usuario a todas las acciones de Amazon SQS en la cola de la cuenta A. Sin embargo, la cuenta B puede delegar el acceso únicamente en la medida en que se haya concedido acceso a dicha cuenta. El grupo de la cuenta B que tenga la segunda política solo puede obtener acceso a la cola entre las 12:00 y las 3:00 el 30 de noviembre de 2014. El usuario solo puede realizar las acciones `SendMessage` y `ReceiveMessage`, según se define en la política de cola de Amazon SQS de la cuenta A. ## No se puede delegar el acceso cuando la cuenta tiene el acceso denegado Una Cuenta de AWS no puede delegar el acceso a los recursos de otra cuenta si la otra cuenta ha denegado de forma explícita el acceso a la cuenta principal del usuario. La denegación se propaga a los usuarios de dicha cuenta independientemente de que tengan políticas que les conceda acceso. Por ejemplo, la cuenta A escribe una política de bucket en el bucket de S3 de la cuenta A que deniega de forma explícita el acceso de la cuenta B al bucket de la cuenta A. Pero la cuenta B escribe una política de usuario de IAM que concede a un usuario de la cuenta B acceso a un bucket de la cuenta A. La denegación explícita aplicada al bucket de S3 de la cuenta A se propaga a los usuarios de la cuenta B. Anula la política de usuario de IAM que concede acceso al usuario de la cuenta B (para obtener más información sobre se evalúan cómo los permisos, consulte [Lógica de evaluación de políticas](reference_policies_evaluation-logic.md).) La política de bucket de la cuenta A podría ser como la siguiente política. En este ejemplo, el bucket de S3 de la cuenta A se llama *amzn-s3-demo-bucket*, mientras que el número de cuenta de la cuenta B es 1111-2222-3333. La cuenta A utiliza Amazon S3 para implementar esta política. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "AccountBDeny", "Effect": "Deny", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } } ``` ------ Esta denegación explícita anula cualquier políticas de la cuenta B que proporcione permiso para obtener acceso al bucket de S3 en la cuenta A.