Creating a Role to Delegate Permissions to an IAM User

bogotobogo.com site search:

Note

We can use IAM roles to delegate access to our AWS resources.

With IAM roles, we can establish trust relationships between our trusting account and other AWS trusted accounts. The trusting account owns the resource to be accessed and the trusted account contains the users who need access to the resource.

We'll be focused on how to use a role to delegate access to resources that are in different AWS accounts that we own (Production and Development).

After we create the trust relationship, an IAM user or an application from the trusted account can use the AWS Security Token Service (AWS STS) AssumeRole API action. This action provides temporary security credentials that enable access to AWS resources in our account.

The accounts can both be controlled by us, or the account with the users can be controlled by a third party. If the other account with the users is in an AWS account that we do not control, then we can use the externalID attribute and a unique identifier supplied by the third-party account. This helps ensure that access occurs only in the correct contexts.

picture source: Delegate Access Across AWS Accounts Using IAM Roles

Creating a Role

On IAM console, choose Roles and then choose Create new role. On the Select role type page, expand the Role for cross-account access section, and then choose the type of role that we want to create:

Choose Select for Provide access between AWS accounts we own if we are the administrator of both the user account and the resource account, or both accounts belong to the same company. This is also the option to choose when the users, role, and resource to be accessed are all in the same account.
Choose Select for Allows IAM users from a 3rd party AWS account to access this account if we are the administrator of the account that owns the resource and we want to grant permissions to users from an account that we do not control. This option requires us to specify an external ID (which the third party must provide to us). With this option, we can exercise additional control over the circumstances in which the third party can use the role to access our resources.
On the next page, specify the AWS account ID to which we want to grant access to our resources.

The administrator of the specified trusted account can grant permission to assume this role to any IAM user in the trusted account. To do this, the administrator attaches a policy to the user or a group that grants permission for the sts:AssumeRole action and that specifies the role's ARN as the Resource.
If we chose Allows IAM users from a 3rd party AWS account to access this account on the Select role type page, type the external ID provided by the administrator of the third party account. This automatically adds a condition to the trust policy that allows the user to assume the role only if the request includes the correct sts:ExternalID.
If we want to restrict the role to users who sign in by using multi-factor authentication (MFA) device, select the Require MFA option. This adds a condition to the role's trust policy that checks for an MFA sign-in. A user who wants to assume the role must sign in with a temporary one-time password from a configured MFA device. Users without MFA authentication cannot assume the role.
Choose Next Step.
On the Attach policy page, choose one or more permissions policies to attach to the role. Choose policies that specify what actions can be done on specific resources (similar to setting permissions for IAM groups).

The permissions that we specify are available to any entity that uses the role. By default, a role has no permissions.

Select the box next to the policy that assigns the permissions that we want the users to have, and then choose Attach policy. We can choose to select no policies at this time, create the policies later, and then attach them to the role.
For Role name, type a suffix to add to the service-linked role default name. This suffix helps us identify the purpose of this role. Role names must be unique within our AWS account. They are not distinguished by case. For example, we cannot create roles named both PRODROLE and prodrole. Because various entities might reference the role, we cannot edit the name of the role after it has been created.
Review the role settings. Note the link provided for we to give to users who can use the role. When the user chooses this link, the user is taken directly to the Switch Role page with the Account ID and Role Name already filled in. The user is asked for credentials if he or she is not already signed in. The user can optionally set a Display Name and can select a Display Color. When the user chooses Switch Role, the user immediately begins operating with the new permissions.
Choose Create role to complete the creation of the role.

Remember that this is only the first half of the configuration required. We must also give individual users in the trusted account permissions to switch to the role.
After we create the role and grant it permissions to perform AWS tasks or access AWS resources, the user can switch to the role.

Ref: Creating a Role to Delegate Permissions to an IAM User

Delegate Access Across AWS Accounts Using IAM Roles

We'll see how to use a role to delegate access to resources that are in different AWS accounts that we own (Production and Development). We share resources in one account with users in a different account. By setting up cross-account access in this way, we don't need to create individual IAM users in each account. In addition, users don't have to sign out of one account and sign into another in order to access resources that are in different AWS accounts. After configuring the role, we see how to use the role from the AWS Management Console, the AWS CLI, and the API.

The Production account is where live applications are managed, and the Development account is a sandbox where developers and testers can freely test applications. In each account, application information is stored in Amazon S3 buckets. We manage IAM users in the Development account, where yweou have two IAM groups: Developers and Testers. Users in both groups have permissions to work in the Development account and access resources there. From time to time, a developer must update the live applications in the Production account. These applications are stored in an Amazon S3 bucket called productionapp.

At the end of this tutorial, we have a role in the Production account (the trusting account) that allows users from the Development account (the trusted account) to access the productionapp bucket in the Production account. Developers can use the role in the AWS Management Console to access the productionapp bucket in the Production account. They can also access the bucket by using API calls that are authenticated by temporary credentials provided by the role. Similar attempts by a Tester to use the role fail.