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
ROLES/STS
  • 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 - 36h)
  • 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 1 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: Applied across multiple accounts
  • Customer Managed Policies: Tied to a single AWS account
  • Inline Policies: Directly attached to user

Types

Resource based policies
  • Specifies a Principal
  • 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
Identity based policies (IAM policies)
  • Attached to a user/group/role (implicit Principal)
  • Limit of 10 managed policies can be attached

Format

Component Description
EFFECT Allow/Deny
SERVICE for which the permission apply
RESOURCE
  • specific ARN for which the permission apply
  • ARN:AWS:SERVICE:REGION:ACCOUNT-ID:[RECSOURCE-TYPE:]RESOURCE
ACTION subset of actions within a service that the permission allows/denies
CONDITION optional additional restrictions that limit the actions allowed (e.g., specify IP range/time interval)

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 programatically as part of AssumeRole

Conditions

Operators Operators are ANDed, multiple values in an operator are ORed
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)

Description
  • 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)

Federation

Description
  • IAM Identity Providers (IDP) = provide ability to federate outside entities with IAM & assign privileges to those users
  • IAM can integrate 2 types of outside IDP
WEB IDENTITIES
  • OIDC (OpenID Connect)
INTERNAL IDENTITIES
  • SAML (for AD, LDAP)
  • ADFS (AD Federation Services) used to federate internal directory to IAM
Functioning
  • Works by returning a temporary token associated with a role to the IDP
  • Actual Role returned is determined via information received from IDP
    • Attributes of the user in the on-premises IDstore
    • Username & auth service of WEB IDstore

Security Token Service (STS)

Description
  • Grants users limited and temporary access to AWS resources
  • Can't be revoked, but you can revoke an IAM user if they created the temporary creds, which invalidates them

Users can come from 3 resources

Federation (Active Directory)
  • Uses SAML
  • Grants temporary access based on the users AD creds
  • Does not need to be a user in IAM
Federation with mobile apps Uses facebook/amazon/google/openid providers to login
Cross account access Let users from one AWS account access resources in another

Web identity federation

Description
  • Lets you give your users access to AWS resources after they have authn with a web-based id provider (amazon, facebook, google)
  • Following authn, the user receives an authn code from the web id provider, which they can trade for temporary AWS security credentials

Cognito

Description
  • Provides Web Identity Federation
  • Provides temporary limited-privileged creds for both/unauth users
  • Acts as an ID broker between app and web ID provider
  • Recommended for all mobile apps AWS services
Functioning
  • After user is auth with provider, an OAUTH/OpenID token returned from the provider is passed by your app to Cognito, which returns a new Cognito ID for the user & a set of temp, limited-priv AWS creds
  • You will be asked to create a new IAM role for end users
    • Has impact on which AWS services they will be able to access
    • By default access to: Cognito sync, mobile analytics
Identity Pools
  • Store of user identity info that is specific to your AWS account
  • Mapping between federated user IDs and Cognito user IDs
    • Enable you to create unique identities for your users and authn them with ID providers
    • Assign IAM roles to user already authn with another IdP
  • Grants temporary AWS creds (either directly from federation, or in exchange for a user pool token)
User Pools
  • User directories used to manage sign-up and sign-in functionality for mobile/web apps
  • Process
    • Users can sign-in directly to the User Pool, or indirectly via an id provider
    • Cognito acts as an ID broker
    • Successful authn generates JWTs

Organizations

Description
  • Account management service which allows to consolidate multiple AWS accounts into an Organization that can be centrally managed
  • Features
    • Centralized, consolidated billing
    • Organize your accounts into groups/OUs for access control
    • Attach policy based controls (Service Control Policies)
Service Control Policy
  • Used to centrally control the use of AWS services across multiple accounts
    • Can be used to create a Permission Boundary
    • Restricting the actions the users/groups/roles in those accounts can do (including root)
  • Features
    • The SCP applies to all OUs and accounts below the OU to which it is attached
    • SCPs can deny access only, they cannot allow