IAM

Users:

• Root User - has all permissions - unable to limit.

• Global service, Up to 5k users per account , New users have no permissions by default

• A user can be a member of up to 10 groups

Policies

• Identity based policy - apples to a user / group / role = controls what action an identity can preform on which resources, under witch conditions
  • inline policy - for a specific user / group / role = deleted if the identity is deleted

• Permissions policy - grants the user of the role the needed permissions to carry out the intended actions on the resource.

• Resource based policy - to an ARN (AWS resource)

• Trust Policy - specifies which trusted account members are allowed to assume the role

• Managed created by AWS / Custom = client created - can be attached to multiple users

Conditions:

aws:username - for a specific user or org (org id) 
aws:sourceip - restrict to a specific IP 
aws:Requested region - to limit to s specific region 
aws:ResourceTag:ec2 - limit to a specific resource tag 
aws:MultiFactor - enforce MFA

for S3: for a specific ARN (bucket) or specific object * 

Tools

IAM Role vs Resource based policies

We can use both to provide cross account access to resources - but :

when you assume a role - you give up your original permissions and are limited only to the role

Permission boundaries

control the max permission level for a user or a role. can be used with SCP’s

IAM Evaluation Logic

IAM Identity Center (AWS SSO)

One login to AWS accounts , business apps SAML 2.0 + windows EC2

Identity providers: Okta, OneLogin, MS AD

Best Practices for IAM

• lock the root user access keys - don’t use root user

• create IAM user for any user

• use groups to assign permissions to IAM users

• least privilege

• start with AWS polices

• use managed polices - not inline

• enable MFA

• use roles

• use polices conditions - source IP for example