IAM
Principals
- Principal
-
- IAM entity that is allowed to interact with AWS resources
- Can be permanent/temporary
- Can represent human/application
Type |
Description |
ROOT USER |
Complete access to the account |
IAM USERS |
- Persistent entities representing people/apps
- IAM Groups
- Can be used to manage users with similar permissions requirements
- When you add IAM users to a group, they inherit the group's permissions
- An IAM group is not an identity because it cannot be referred to as a Principal when you're setting up permission policies
|
ROLES |
- Roles are used to grant specific PRIVILEGES to specific ACTORS for a SET DURATION OF TIME
- When actor assumes a role → AWS gives him a temporary security token from STS (Security Token Service)
- Expiration needs to be specified when requesting an STS token (
15mins to 36h , default 1h ) - Actors can be authenticated against AWS or some trusted external service
- Use Cases
- Federated (non-AWS) user access (see below)
- Cross-Account Access: setup roles to provide users who have permissions in one account to access resources under another account
- SAML 2.0
- Create trust between your org Identity Provider (IdP) & other orgs as Service Providers
- Configure AWS as the Service Provider & use SAML to provide users with federated SSO to AWS Console
- EC2 Roles (grant permissions to apps running on EC2) → no fixed access key that must be rotated
|
Authentication
Type |
Description |
Username/Password |
Human principals |
Access Key |
- Application principals
ACCESS KEY ID (20chars) + ACCESS SECRET KEY (40chars)
|
Access Key with Session Token |
- Process operating under an assumed role
TEMPORARY TOKEN = ACCESS KEY (2 parts) + SESSION TOKEN
|
- Users
Admin user
= access to everything apart from billing
Power user
= access to everything except IAM
- Multifactor
- Root user can recover from lost second factor by verifying email address + phone number ownership
- APIs can require it by adding condition statements (
aws:MultiFactorAuthPresent
, aws:MultiFactorAuthAge
)
- Doesn't work with federation
Authorization
Policies
- JSON document that fully defines a set of permissions to access/manipulate AWS resources
- 1 policy contains 1+ permissions
Provenance
Provenance |
Description |
AWS Managed Policies |
Provided and managed by AWS |
Customer Managed Policies |
Tied to a single AWS account |
Inline Policies |
Directly attached to the entity |
Types
|
|
Identity-based policies (IAM policies) |
- Attached to a user/group/role (implicit
Principal ) - Limit of 10 managed policies can be attached
|
Resource-based policies |
- Allows to directly attach permissions to AWS resources
- Also allows you to specify who has access to that resource even if it does not have an explicit identity-based policy that says so
- Characteristics
- Specifies a
Principal (no IAM Groups) - Can't be managed policies (always inline)
- Not actually IAM policies at all (just use the same policy language)
- Examples: Organizations (SCP), S3, API Gateway, Lambda, KMS, SNS, SQS, SES
|
Component |
Description |
VERSION |
- Version of the policy language
- The latest version is
2012-10-17
|
STATEMENT |
Contains the remaining elements of the policy |
SID (Optional) |
An identifier used to differentiate statements |
EFFECT |
Allow /Deny |
PRINCIPAL |
- Only when defining resource-based policies (in identity-based policies, the principal is implicit)
- Defines which principal is affected by that specific statement
|
ACTION |
List of methods the policy allows/denies |
RESOURCE |
- Only when you're defining identity-based policies
- Specific ARN for which the permission apply:
ARN:AWS:SERVICE:REGION:ACCOUNT-ID:[RECSOURCE-TYPE:]RESOURCE
|
SERVICE (optional) |
For which the permission apply |
CONDITION (optional) |
Sdditional restrictions that limit the actions allowed (e.g., specify IP range/time interval) |
Sample S3 read-only JSON policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
Additional Limits
|
|
Permissions boundaries |
- Define the maximum permissions that an identity-based policy can grant to an IAM entity
- The boundaries assigned to the user or role do not give them permissions, but rather define the limits of the permissions attached to them
- Unlike SCPs, can specify resources and use conditions
 |
Service Control Policies (SCPs) |
See Organizations |
Session policies |
Like a permission boundary, optionally passed programmatically as part of AssumeRole |
Sample Permission Boundary: Restrict Administrator Policy
- Permission boundary:
{
"Version": "2012-10-17",
"Statement": [
{
"SID": "AllowAmazonS3AccessOnly",
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*"
}
]
}
- Although the user has a permission policy that gives administrator access, if he tries to access any other resources or services besides S3, it fails due to the permissions boundary assigned to him
Conditions
|
|
Operators |
Operators are in AND , multiple values in an operator are in OR |
Sources |
- time, MFA, secure transport, user agent
aws:source{Vpc,Vpce (endpoint),Account,Arn,Ip}
|
Principals |
aws:PrincipalOrgID (instead of listing lots of accounts, just use the Org)aws:PrincipalTag/ aws:PrincipalType aws:userid , aws:username
|
NotAction |
Matches everything except the list of actions |
(Not)Principal |
- AWS - users, roles, accounts
- Federated (no info on the role)
- Service (in trust policies)
AWS:* (IAM identities, not services)
|
Policy Association (authz)
Handled in IAM by defining specific privileges in POLICIES & associating those policies with principals
Associate POLICY - IAM USER
|
|
USER Policy |
exists only in the contest of the user |
MANAGED Policy |
exists independently of users & can be associated with many users/groups |
GROUPS |
simplify managing permissions for large number of users (teams) |
Associate POLICY - IAM GROUP
|
|
GROUP Policy |
exists only in the contest of the group |
MANAGED Policy |
can also be associated with IAM groups |

ASSUMING A ROLE
Grant access to a 3rd party Account
"Principal": {"AWS": "3rd party AWS account ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by 3rd party"}}
Policy Resolution
-
- Request
DENIED
by default
- Evaluate policies: if explicit
DENY
found → DENY
- If NO explicit
DENY
& explicit ALLOW
→ ALLOW
- If NO explicit
ALLOW/DENY
→ default DENY
- EXCEPTION = if an
AssumeRole
call includes a role and a policy, the policy cannot expand the privileges of the role (cannot override any permission denied by default in the role)
