| « PreviousNext » | |
   | Did this page help you? Yes | No | Tell us about it... |
Roles
IAM roles allow you to delegate access to users or services that normally don't have access to your organization's AWS resources. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls. Consequently, you don't have to share long-term credentials or define permissions for each entity that requires access to a resource. The following scenarios highlight some of the challenges that you can address by delegating access:
- Granting applications that run on Amazon EC2 instances access to AWS resources
To grant applications on an Amazon EC2 instance access to AWS resources, developers might distribute their credentials to each instance. Applications can then use those credentials to access resources such as Amazon S3 buckets or Amazon DynamoDB data. However, distributing long-term credentials to each instance is challenging to manage and a potential security risk.
- Cross-account access
To control or manage access to resources, such as isolating a development environment from a production environment, you might have multiple AWS accounts. However, in some cases, users from one account might need to access resources on the other account. For example, a user from the development environment might require access to the production environment to promote an update. Therefore, users must have credentials for each account, but managing multiple credentials for multiple accounts makes identity management difficult.
Instead of creating and distributing multiple credentials, you can delegate API access by using IAM roles. You create a role in the AWS account where you want to delegate access. When you create the role, you specify two policies: one that defines who can assume the role (the trusted entities) and another that defines what actions can be done on which resources. You can specify account IDs or AWS services as trusted entities.
For IAM users to assume the role, they must be granted permission to call
sts:AssumeRole for that specific role. After assuming the role, the user
can use the role's temporary security credentials to access resources that are defined in
the role. With the temporary security credentials, the user acts as the role and has only
the permissions that are associated with the role. Callers can further restrict permissions
by passing an additional policy when they assume a role.
For details about how you can use roles to delegate API access, see the following scenarios:
