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

<aside> 💢

AWS Grant permissions to IAM Users based on their job functions,(AdministratorAccess for Administrators and PowerUserAccess for Developer Power Users.)

</aside>

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

<aside> ✍🏻 Access advisor - to see permissions granted and when last used

</aside>

<aside> 🗣️ Access analyzer - review resources that are shared with external entity's. (S3,IAM,KMS,Lambda,SQS) can validate policy for best practices, and get recommendations & policy generation based on activity

</aside>

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