IAM Policies, Roles and Evaluation

What it is

AWS Identity and Access Management (IAM) decides whether a request is allowed. At professional level the questions are less about writing one policy and more about predicting the outcome when several policy types apply at once.

The safest model for people and machines is short lived credentials from roles, not long lived access keys. Roles are assumed through the AWS Security Token Service (STS), which returns temporary credentials.

How it works

Policy types

Only identity and resource policies grant access. Boundaries, SCPs and session policies only limit.

Evaluation logic

1. Everything is denied by default.
2. An explicit Deny in any applicable policy ends the evaluation with a deny.
3. For an allow to stand, every limiting layer that applies (SCP, permission boundary, session policy) must also allow the action.
4. An allow from an identity policy or a resource policy then grants access.

Within one account, a resource policy that names the principal can grant access even if the identity policy says nothing. Across accounts, both sides must allow: the identity policy in the caller's account and the resource policy in the owner's account. When a role is assumed in the other account, the request is evaluated in that account as the role.

Roles and trust

A role has two policy parts. The trust policy says who may assume the role. The permissions policy says what the role can do after it is assumed.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
    "Action": "sts:AssumeRole",
    "Condition": {"StringEquals": {"sts:ExternalId": "example-id-123"}}
  }]
}

An external ID protects a role that a third party assumes on your behalf against the confused deputy problem, where another customer of the third party tricks it into assuming your role on that customer's behalf.

aws sts assume-role --role-arn arn:aws:iam::444455556666:role/AuditRole \
  --role-session-name audit-check

Services use roles too: an EC2 instance profile, a Lambda execution role, an ECS task role. To let a user or service hand a role to a service, they need iam:PassRole for that role, which is a common privilege escalation path, so scope it to specific role ARNs.

Permission boundaries

A permission boundary is a managed policy that caps a role or user. It lets you delegate role creation safely: a developer may create roles, but only if the new role carries the boundary, so it can never exceed the ceiling.

Attribute based access control

Attribute based access control (ABAC) uses tags to scale permissions. One policy applies to many resources, and access follows tags on the principal and the resource.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ec2:StartInstances", "ec2:StopInstances"],
    "Resource": "*",
    "Condition": {
      "StringEquals": {"aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"}
    }
  }]
}

New teams and projects need only tags, not new policies. Session tags can pass attributes from an identity provider into the assumed role.

Useful condition keys

Least privilege tools

• IAM Access Analyzer finds resources shared outside your account or organization, flags unused access, validates policies and can generate a policy from CloudTrail activity.
• Last accessed information shows which services and actions a role actually used.
• The policy simulator tests what a principal can do before you deploy.
• Credential reports list users and the age of their keys and passwords.