|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
Sometimes you need to temporarily delegate access to users or services that normally don't have access to your AWS resources. For example, a user in one AWS account might need access to resources in another account. Or a mobile app might use AWS resources, but you don't want to store AWS keys with the app where they can be difficult to rotate and where users can potentially extract them.
For these scenarios, you can delegate access to AWS resources using IAM roles. A role lets you define a set of permissions to access the resources that a user or service needs, but the permissions are not attached to an IAM user or group. Instead, at run time, applications or AWS services (like Amazon EC2) can programmatically assume a role. When a role is assumed, AWS returns temporary security credentials that the user or application can use to make programmatic requests to AWS. Consequently, you don't have to share long-term security credentials (for example, by creating an IAM user) for each entity that requires access to a resource.
You create a role in the AWS account that contains the resources that you want to allow access to. When you create the role, you specify two policies. The trust policy specifies who is allowed to assume the role (the trusted entity, or principal). The access (or permissions) policy defines what actions and resources the principal is allowed access to. The principal can be an AWS account, an AWS service such as Amazon EC2, a SAML provider, or an identity provider (IdP) such as Login with Amazon, Facebook, or Google.
The following scenarios describe ways you can use roles to delegate access to your AWS resources.
If an application runs on an Amazon EC2 instance and needs to make requests for AWS resources such as Amazon S3 buckets or an Amazon DynamoDB table, it must have security credentials. It isn't a good practice to embed or pass IAM user credentials to each instance—distributing long-term credentials to each instance is challenging to manage and a potential security risk. A better strategy is to create a role that is used when the Amazon EC2 instance is launched. An application can then get temporary security credentials from the Amazon EC2 instance. For more information, see Granting Applications that Run on Amazon EC2 Instances Access to AWS Resources.
To manage access to resources, you might have multiple AWS accounts—for example, to isolate a development environment from a production environment. However, users from one account might need to access resources in the other account, such as promoting an update from the development environment to the production environment. Although users who work in both accounts could have a separate identity in each account, managing credentials for multiple accounts makes identity management difficult. Instead, you can create a role in an account that lets a user from the other account securely access resources. For more information, see Cross-Account API Access Using IAM Roles.
Users might already have identities outside of AWS, such as in your corporate directory. However, those users might need to work with AWS resources (or work with applications that access those resources). If so, users also need AWS security credentials in order to make programmatic requests to AWS. To provide these credentials, you can use IAM roles, which let you specify permissions for users whose identity is federated from your organization. For more information, see Using Your Company's Own Authentication System to Grant Access to AWS Resources and Creating Temporary Security Credentials to Enable Access for Federated Users in the Using Temporary Security Credentials guide.
If your organization supports SAML 2.0 (Security Assertion Markup Language 2.0), you can create trust between your organization as an identity provider (IdP) and other organizations as service providers. In AWS, you can configure AWS as the service provider and use SAML to provide your users with federated single-sign on (SSO) to the AWS Management Console or to get federated access to call AWS APIs. For more information, see Creating Temporary Security Credentials for SAML Federation in the Using Temporary Security Credentials guide.
If you create a mobile or web-based app that accesses AWS resources, the app needs security credentials in order to make programmatic requests to AWS. But you shouldn't embed long-term security credentials in the app, because they are accessible to the app's users and can be difficult to rotate. Instead, you can let users sign in to your app using Login with Amazon, Facebook, or Google, and then use their authentication information to assume a role and get temporary security credentials. For more information, see Creating a Mobile App with Third-Party Sign-In and Creating Temporary Security Credentials for Mobile Apps Using Identity Providers in the Using Temporary Security Credentials guide.