AWS has two kinds of IAM identity that people often mix up: users and roles. They both carry permissions, but they handle credentials very differently. Here is what each one is, how a server gets its role's credentials, and why AWS recommends temporary credentials for workloads, with links to the AWS documentation itself.
- What it is
Two identities, different credentials.
An IAM user is an identity in your account that consists of a name and credentials, such as a console password or access keys. An IAM role is also an identity with permission policies, but instead of belonging to one person it is meant to be assumable by anyone who needs it, and it has no standard long-term credentials such as a password or access keys. When you assume a role, it provides temporary security credentials for your role session. A role can be assumed by, among others, an IAM user, an AWS service such as EC2 or Lambda, or an external user signed in through a SAML 2.0 or OpenID Connect identity provider. AWS still names cases where a user fits better (for example workloads that cannot use roles), and recommends them only for use cases that federation does not support.
Source: AWS, IAM User Guide, IAM roles; IAM users
- How it works
A server gets its role's credentials.
On Amazon EC2, an instance profile is attached to the instance and contains the role. The application obtains the role's temporary security credentials from the EC2 instance metadata (some AWS SDKs do this for you), and uses them to sign its AWS API requests. The credentials available on the instance update automatically before they expire, so a valid set is always available. The temporary credentials themselves are generated by the AWS Security Token Service (AWS STS). If you use the IAM console, the instance profile is managed for you; with the CLI or API you create it as a separate step. An instance can have one role at a time, and every application on it shares that role's permissions.
Source: AWS, IAM User Guide, IAM roles for Amazon EC2; Temporary security credentials in IAM
- Why it matters
Temporary credentials expire.
Temporary security credentials can be set to last anywhere from a few minutes to several hours. After they expire, AWS no longer recognizes them or allows any access with them, so you do not have to update or explicitly revoke them. Long-term credentials such as access keys are different: AWS recommends updating them when needed, for example when an employee leaves the company. That is why the AWS best practices say workloads should use temporary credentials with IAM roles, so no long-lived key has to be distributed to the workload, and why permissions should be least privilege, granting only what the task requires.
Source: AWS, IAM User Guide, Security best practices in IAM; Temporary security credentials in IAM
The takeaway: A user holds long-term credentials. A role hands out temporary ones. For workloads, AWS recommends a role with least-privilege permissions over a long-term key you have to keep updating. Where you cannot use roles, AWS still lists IAM users with long-term access keys as the fallback, and recommends updating those keys when needed.
More short lessonsADIR also offers a free external pen test for cloud teams: see the offer.
Transcript
In AWS, users and roles can both hold permissions. But only one of them comes with a password or access keys. An IAM user is an identity with long-term credentials, like a password or access keys. An IAM role is an identity too, but it has no standard long-term credentials. When you assume the role, you get temporary security credentials. Here's how it works on an EC2 server. An instance profile carries the role. The app gets the role's temporary credentials from the instance metadata, and signs its AWS requests with them. They refresh before they expire. Here's why it matters. Temporary credentials last from a few minutes to several hours, and then AWS no longer recognizes them. An access key keeps working until someone updates or removes it. So AWS recommends roles for workloads, with only the permissions the job needs. So, a user holds long-term credentials. A role hands out temporary ones. And for workloads, a role with least privilege beats a long-term key you have to keep updating.
Narrated with an AI voice.
