- When accessing AWS, the root account should never be used. Users must be created with the proper permissions. IAM is central to AWS
- Users: A physical person
- Groups: Functions (admin, devops) Teams (engineering, design) which contain a group of users
- Roles: Internal usage within AWS resources
- Cross Account Roles: roles used to assumed by another AWS account in order to have access to some resources in our account
- Policies (JSON documents): Defines what each of the above can and cannot do. Note: IAM has predefined managed policies
- There are 3 types of policies:
- AWS Managed
- Customer Managed
- Inline Policies
- There are 3 types of policies:
- Resource Based Policies: policies attached to AWS services such as S3, SQS
- When we assume a role (user, application or service), we give up our original permission and take the permission assigned to the role
- When using a resource based policy, principal does not have to give up any permissions
- Example: user in account A needs to scan a DynamoDB table in account A and dump it in an S3 bucket in account B. In this case if we assume a role in account B, we wont be able to scan the table in account A
- One IAM User per person ONLY
- One IAM Role per Application
- IAM credentials should NEVER be shared
- Never write IAM credentials in your code. EVER
- Never use the ROOT account except for initial setup
- It's best to give users the minimal amount of permissions to perform their job