Skip to content

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

Format

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

  • Actor can be
    • Authenticated with IAM User (person/process)
    • Person/process authenticated by trusted external service (AWS service will assume the role on the actor's behalf & return a token to the actor)
  • After an actor has assumed a role, it is provided with a temporary security token associated with policies of that role

  • Each IAM role has 2 policies:

    Policy Description
    Permission Policy Specifies what the role allows someone to do
    Trust Policy Specifies who can assume the 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

  1. Request DENIED by default
  2. Evaluate policies: if explicit DENY found → DENY
  3. If NO explicit DENY & explicit ALLOW → ALLOW
  4. If NO explicit ALLOW/DENY → default DENY
  5. 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)