IAM roles and temporary credentials

Why credentials matter

Every request to AWS is signed with credentials, and those credentials decide what the request is allowed to do. AWS credentials come in two broad kinds:

• Long-term credentials, such as an IAM user's password and access keys, or the root user's sign-in details. They stay valid until someone changes or deletes them.
• Temporary credentials, which you receive when you assume an IAM role. They expire on their own.

If long-term credentials leak, they keep working until someone notices. Temporary credentials limit that window. This is why AWS security guidance recommends relying on temporary credentials wherever possible.

The root user

Every AWS account starts with a root user that has complete access to every resource in the account, including billing. AWS recommends that you:

• Do not use the root user for everyday work. Create administrative identities instead.
• Do not create access keys for the root user.
• Protect root sign-in with multi-factor authenticationMFA (Multi-factor authentication)Signing in with two or more different kinds of proof, such as a password plus a code from a phone app or a security key. AWS recommends MFA for the root user and for every human user.Glossary entryClose (MFA). AWS requires MFA for the root user of every account type.
• Keep the root user for the small set of tasks that only it can perform.

In AWS Organizations, you can go further and remove root user credentials from member accounts entirely.

Roles instead of shared users

An IAM role is an identity with permissions but without a long-term password or access keys. When a person or service assumes the role, AWS issues temporary security credentials for that session. Roles fit three common situations.

People

For a single AWS account, give people access through IAM roles rather than individual IAM users with long-term keys. For multiple accounts managed with AWS Organizations, AWS recommends IAM Identity Center, which manages workforce users and their permissions across accounts. Either way, everyone signs in with their own identity, which keeps actions traceable to a person.

Applications on Amazon EC2

An application running on an EC2 instance should not store access keys in its code, configuration files, user data, or machine image. Instead, attach an IAM role to the instance through an instance profile. The application then receives temporary credentials for the role, and they are rotated automatically.

Access across accounts

When an application in account A needs a resource in account B, account B creates a role that:

1. Has a permissions policy granting only the access that is needed.
2. Has a trust policy naming the principalPrincipalA person or workload that can make requests to AWS, such as an IAM user, a role session, the root user, a federated user, or an AWS service. Resource-based policies name the principals they allow.Glossary entryClose in account A that may assume it.

The application calls the AWS STS AssumeRole operation and receives temporary credentials for the role. Permissions in account A alone are not enough: the account that owns the resource must also allow the access.

Least privilege

Whatever identity you use, grant only the actions and resources it needs. For example, an application that only uploads files to one prefix of an S3 bucket needs a single action:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "s3:PutObject",
			"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/uploads/*"
		}
	]
}

Broad managed policies such as AdministratorAccess or AmazonS3FullAccess are convenient, but they turn a small mistake into a large one.

Guardrails across many accounts

In AWS Organizations, service control policies (SCPsSCP (Service control policy)An AWS Organizations policy that sets the maximum permissions for IAM users and roles in member accounts. It grants nothing by itself, and it does not apply to the management account.Glossary entryClose) set the maximum permissions for IAM users and roles in member accounts, including the member account's root user. Two points are easy to miss:

• An SCP never grants permissions. It only limits what identity-based and resource-based policiesResource-based policyA permissions policy attached to a resource, such as an S3 bucket policy or an SQS queue policy, that says which principals can use it, including principals in other accounts. Identity-based policies, in contrast, attach to users, groups, and roles.Glossary entryClose can allow.
• SCPs do not affect users or roles in the organization's management account.

SCPs are preventive. A tool such as AWS Config, by contrast, detects and reports a noncompliant resource after it exists.

Key takeaways

• Prefer temporary credentials from roles over long-term access keys.
• Use the root user only for tasks that require it, protect it with MFA, and give it no access keys.
• Give EC2 applications credentials through an instance profile, never through stored keys.
• Use roles and AWS STS for cross-account access.
• Use SCPs for organization-wide limits that account administrators cannot override.

Sources

• IAM User Guide: Root user best practices
• IAM User Guide: Security best practices in IAM
• Amazon EC2 User Guide: IAM roles for Amazon EC2
• Amazon EC2 User Guide: Retrieve security credentials from instance metadata
• IAM tutorial: Delegate access across AWS accounts using IAM roles
• AWS Organizations User Guide: Service control policies