Next up is reading through the section of the AWS IAM documentation about roles. I’m going to continue to use bullet-point lists here for notes.
RoleName attributes are limited to 64 characters, but can have an prepended
Path of up to 512 additional characters. However, roles where the length of
RoleName is greater than 64 characters cant’s be switched to via the Console - they’re essentially API-only. This is rooted in the combined
RoleName value being stored as a browser cookie.
How long you can assume a role for varies a lot, and can be controlled via URL construction or API call up to the maximum session duration defined for that role (or to 12 hours for roles assumed via a URL, which happens to be the maximum value for the maximum session duration).
There’s a hard limit of 1 hour, however, when you chain roles together (assuming one, and then using that role to assume another).
If you try to assume a role for longer than the maximum duration allowed in a given context, the operation will fail. Which is unfortunate, as that means that before assuming a role on behalf of a user any process would need to call
aws iam get-role / the
GetRole API if the intention is to assume the role for as long as possible.
Role time limits apply only to users - AWS services and applications running on EC2 instances are exempt.
As noted above, using cross-account roles (or services) requires the cooperation of both accounts: The account being granted permission to use the role must still explicitly make that role (or service) available to its users.
Root users cannot switch roles.
Roles that require an
ExternalId can only be accessed over the API.
Switching roles using the admin console does not appear to allow for role chaining.
AssumeRole events are tracked by CloudTrail.
PassRole cannot be used with cross-account roles.
Three things are required for a user to pass a role to a service: (1) The role itself, (2) a “trust policy” attached to the role that allows the service in question to call
sts:AssumeRole, and (3) an IAM policy attached to the user passing the role that allows
iam:PassRole for the role resource ARN.
The user passing a role doesn’t need to have access to that role themselves - they just need permission to pass it.
Role names cannot be changed. But surprisingly, role
Path parameters can be changed.
You can create a profile for the AWS CLI that automatically assumes a role by specifying two parameters in the associated
role_arn (obviously the ARN of the role to be assumed) and
source_profile (the name of an existing profile that has permission to assume
role_arn). When the AWS CLI is being used on an EC2 instance that has an existing role,
credential_source = Ec2InstanceMetadata needs to be used instead of
The requirements to allow a service to assume a role are similar to those to allow a user to pass a role: (1) The role itself, (2) a “trust policy” attached to the role that allows the role that allows the role attached to the service (see next requirement) to call
sts:AssumeRole, and (3) an role attached to the service itself that allows it to call
sts:AssumeRole for the first role resource ARN. This is again the pattern where AWS requires that trust relationships be bidirectional.
When calling the
AssumeRole API, you can pass in a JSON
Policy or up to 10 ARNs for pre-defined policies (using
PolicyArns). The session that is returned will then have the intersection of the permissions of the role being assumed and the provided policies (so these can be thought of as additional limits). This mostly seems to be for when credentials need to be handed off to another user or service.
Applications that run on an EC2 instance automatically inherit the role assigned to that instance.
The role assigned to an EC2 instance is defined in the “instance profile”.
EC2 is just a service, so the requirements for EC2 instances to use roles (and for developers to assign roles to EC2 instances) are identical to those for a user who wishes to pass a role to a (generic) service.
That said, allowing an EC2 instance to use a role as part of its “instance profile” does require that the role assigned to the “instance profile” also has a trust policy specifying that EC2 is allowed to call
Instance profiles and roles are linked in the management console; instance profiles will be automatically created and deleted as needed, and are never directly exposed.
Instance profiles created using the API can also be managed in the console if and only if they have they same name as they associated role.
Tags can only be added to instance profiles using the API.
Changes to instance profiles are not applied instantly, but are rather subject to eventual consistency.
Temporary credentials associated with a role can be revoked before a given point in time. They cannot be revoked per-user.
Revocation is handled by attaching an inline policy to the role that denies all actions before the specified point in time (“now”).
The inline policy will be refreshed automatically with a new point in time denial timestamp if sessions are revoked again at a later time.
AWS CLI users who have their credentials revoked in this way will either need to wait until their session would have expired (which could be up the 12 hours, depending on the role configuration) or manually delete the AWS CLI credential cache (~/.aws/cli/cache).