In a nutshell:
With IAM, you have users, groups, roles, and policies.
Users log in with a username and password and by default they have no permissions.
Groups are groupings of users and roles are identities that you can assume to gain access to temporary credentials and permissions for a configurable amount of time.
In order to give permissions to an identity, you need to create policies that either explicitly allow or deny a specific action in AWS.
Roles are used to grant temporary additional permissions for entities that are already authenticated to AWS.
AWS Identity and Access Management (IAM) lets you manage access to AWS services and resources.
We've had a brief play around with IAM at the start of the course - do you remember learning about the root user and creating different IAM users with different access policies?
Let's dive back into IAM, this time with the lens of how IAM helps companies as a governance service.
AWS account root user
When you first create an AWS account, you begin with an identity known as the root user.
- You can think of the root user as being the owner of the account.
- It has complete access to all the AWS services and resources in the account. It cannot be restricted.
- To access the root user, just sign in with the email and password you used to create your AWS account.
Best practice
- Do not use the root user for everyday tasks.
- Instead, use the root user to create your first IAM user and assign it permissions to create other users.
- Then, continue to create other IAM users, and access those identities for regular tasks throughout AWS.
- As soon as you create an AWS account and log in with your root user, turn on multi-factor authentication (MFA). We'll dive into MFA in the next topic!
- As a quick refresher, other security tips include locking away the root user's credentials, and rotating access keys and the password for the user.
- Only use the root user for tasks that are only available to the root user. For example, changing your root user email address and changing your AWS support plan.
IAM users
An IAM user is an identity that you create in AWS.
- It represents a person or app that interacts with AWS services and resources.
- It includes a name and credentials.
- By default, when you create a new IAM user in AWS, it has no permissions associated with it. The user can't even log into the AWS account at first, it has absolutely zero permissions.
- To allow the IAM user to perform specific actions in AWS, such as launching an Amazon EC2 instance or creating an Amazon S3 bucket, you must grant the IAM user the necessary permissions.
Best practice
- Create individual IAM users for each person who needs to access AWS.
- Even if you have multiple people who need the same level of access, you should create individual IAM users for each of them. A unique set of security credentials for each user = additional security.
- It's similar to security in an apartment - it's not so secure that everyone living there knows the password to the big gate, so it's more secure that everyone has their own lock and key for their door.
The way that you grant or deny permission is to associate what is called an IAM policy to an IAM user.
IAM policies
An IAM policy manages permissions to AWS services and resources.
- In a more technical definition, an IAM policy is a JSON document that describes what API calls a user can or cannot make.
- There were only two potential options for the effect on any policy. Either allow or deny.
- You can also customise the level of access. For example, you can allow users to access all of the Amazon S3 buckets in your AWS account, or only a specific bucket.
Best practice
- Follow the security principle of least privilege when granting permissions. This means preventing users, roles, group and policies from having more permissions than needed.
- For example, if an employee needs access to only a specific bucket, don't grant them access to all buckets in your AWS account.
One way to make it easier to manage users and permissions is to organise them into IAM groups.
IAM groups
An IAM group is a collection of IAM users.
- When you assign an IAM policy to a group, all users in the group are granted permissions specified by the policy.
- This helps save you heaps of time. Instead of assigning permissions one by one, you can create a group for all the IAM users, and attach permissions to the group in one go.
- Assigning IAM policies at the group level also makes it easier to adjust permissions when an employee transfers to a different job.
- For example, if a developer becomes a data scientist, the manager can easily remove them from the “Developers” group and adds them into the “Data Scientist” group.
- This ensures that employees have only the permissions that are required for their current job.
But what if an employee rotates through different jobs in a week, and need access to different services at different times? This employee can get the access they need through IAM roles.
IAM roles
You use IAM roles to give temporary access to entities like AWS services, users, applications, or even users from different AWS accounts. Note that roles are not for logging in like a username and password - roles grant additional access to an entity's existing permissions. Here's how it works:
- Imagine you're a user that's already logged into AWS. You need to retrieve data from a database, but your user does not have access to it! You request permission for a specific IAM role that would give you access to the database.
- The owner of the IAM role has already set up trust policies (i.e. rules) that define who can get permission if they request it. If you meet the criteria in the trust policy - voila! You get permission automatically.
- Now, you have temporary access to retrieve data from the database, and you get to set the duration of your access. This access can be set for a specific time (down to the number of seconds!) with a maximum limit of 12 hours.
- Note: when someone takes on an IAM role, they also give up all previous permissions they had from a previous role.
Best practice
- IAM roles are ideal for situations where access needs to be granted temporarily, instead of long-term.
- IAM roles work great for users with responsibilities and access that change day to day
