IAM Policies, Roles and Access

What it is

AWS Identity and Access Management (IAM) controls who can do what in your account. A principal (a user, role or application) sends a request, and IAM decides whether to allow it by evaluating policies.

The main identities are IAM users (long lived credentials, avoid where possible), groups of users, and roles. A role has no password or access key of its own. Instead, a trusted principal assumes it and receives temporary credentials from the AWS Security Token Service (STS).

How it works

Policy types

A permissions boundary and an SCP never grant anything by themselves. They only limit what other policies can grant.

Evaluation logic

IAM starts from an implicit deny. Then it applies these rules.

1. An explicit Deny in any applicable policy always wins.
2. Otherwise, the request needs an Allow, and the allow must also fit within any SCP, permissions boundary and session policy.
3. If there is no allow, the request is denied.

In the same account, an allow in either the identity policy or the resource policy is enough. For cross account access, both the resource's account (through its resource policy) and the caller's account (through an identity policy) must allow.

A small identity policy that follows least privilege:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::reports-bucket/*",
    "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
  }]
}

Conditions refine when a statement applies. Common keys include aws:SourceIp, aws:RequestedRegion, aws:PrincipalOrgID and aws:MultiFactorAuthPresent.

Roles

A role has two policies. The trust policy says who may assume it, and the permissions policy says what it can do.

EC2 instances use a role through an instance profile, and Lambda functions use an execution role. This removes the need to store access keys on servers.

# AWS CLI: assume a role and receive temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/ReadOnlyAudit \
  --role-session-name audit-check

Cross account access uses a role in the target account that trusts the other account. For workforce sign in to many accounts, IAM Identity Center provides single sign on with permission sets.

Hardening the account

• Protect the root user with MFA (multi factor authentication), and do not use it for daily work or create access keys for it.
• Require MFA for people with console access, and set a password policy.
• Rotate or remove unused access keys. The credential report lists users and the age of their passwords and keys.
• IAM Access Advisor shows when a service was last used by an identity, which helps you trim permissions.
• IAM Access Analyzer finds resources shared outside your zone of trust, validates policies and can highlight unused access.

Troubleshooting AccessDenied

Work through the layers in order.

1. Is there an explicit Deny in any policy?
2. Does an SCP or permissions boundary block the action?
3. Does the identity policy allow the action on this resource ARN?
4. For cross account access, does the resource policy also allow?
5. For KMS or S3 encrypted data, does the key policy allow use?
6. Do conditions (MFA, IP, Region, tags) match the request?

The IAM policy simulator tests what a policy would allow. CloudTrail shows the denied call and who made it. For some services, an encoded failure message can be decoded with aws sts decode-authorization-message.