Skip to content

IAM

Principals

Principal
  • IAM entity that is allowed to interact with AWS resources
  • Can be permanent/temporary
  • Can represent human/application

Types

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

Description
  • JSON document that fully defines a set of permissions to access/manipulate AWS resources
  • 1 policy contains 1+ permissions

Provenance

  • 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": "*"
        }
    ]
}

Features

Permissions boundaries
  • Set the maximum permissions that an identity-based policy can grant to an IAM entity
  • 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

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

Associating 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

Policy Resolution

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

Permission Boundaries

Description
  • Allow to define the maximum permissions a user or application can be granted by IAM identity-based policies
  • The boundaries assigned to the user or role do not give them permissions, but rather define the limits of the permissions attached to them

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