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

---

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