Introduction 

Hello everyone,

Welcome to our blog where we’re going to talk about something really awesome that keeps our Amazon Web Services (AWS) stuff safe and organised. Imagine you have a super cool clubhouse in the cloud, filled with different rooms of gadgets and fun things. But you want only the right friends to come in and play with specific toys. That’s exactly what Identity and Access Management also known as IAM does for your AWS clubhouse – it’s like the superhero who makes sure the right buddies have the right keys!

In this exciting adventure, we have three main characters: IAM users, roles, and policies. IAM users are like buddies who want to use your AWS toys. Roles are like special hats that buddies wear when they need to do something special, like being a superhero for a day. Policies are like the rules that IAM uses to decide who can join the party and what they can do.

So, get ready to explore the world of IAM in AWS with us. We’ll show you what IAM users, roles, and policies are, why they’re super important, and how they work together to keep everything safe and fun in your AWS playground. Let’s dive in and learn about IAM – the guardian of your AWS adventures!

What is IAM 

AWS Identity and Access Management (IAM) is like a security guard for AWS services. It controls who can use what and how within AWS.

Imagine IAM as having two main roles:

Proving Who You Are (Authentication):

This is similar to showing an ID before entering. When you want to use AWS, you have to confirm your identity. Usually, you do this with a username and password. Sometimes, you might need an extra step, like entering a code from your phone.

Deciding What’s Allowed (Authorization):

Simply getting inside doesn’t mean you can do everything. Some parts might be restricted or have specific rules. Once you prove your identity, IAM ensures you only have access to what you’re supposed to. It’s like getting a special badge that lets you into specific areas.

Let’s see the three main Identities of IAM

IAM Identities: Users, Groups, Roles

IAM makes sure the right people use the right things in the right way in AWS.

IAM handles different types of important things called identities: root user, users, user groups, and roles. These identities determine who the user is and what they’re allowed to do in the system.

AWS Root User, Groups, and Users:

Let’s see one by one : 

Root User: When you first make an Amazon Web Services (AWS) account, you start with one main sign-in identity. This identity has full access to all AWS services and resources in the account. It’s known as the AWS account root user, and you log in using the email and password you used to create the account.

IAM Users:

 An IAM user is like a character you create in the AWS world. This character stands for a person or service that interacts with AWS using this identity. IAM users are mainly used to let people log in to the AWS Management Console for hands-on tasks and to make computerised requests to AWS services through APIs or the command-line interface (CLI). An IAM user has permanent, long-lasting credentials and is directly used to talk to AWS services.

Hands On :

To create User , follow below steps:

1. First navigate to the IAM dashboard,
   
   

2. Click on user , then click on create user as shown in below image.
   
   

3. Now we have to give a user name, then if you want to give this user console access then select the checkbox, then we have to create a password for this user, here we have two options either you can get it automatically by selecting the first option and you can customize it by selecting the second option as shown in image, and click on the next.

4. Then here you can see three options. First is Add User to Group: This option involves adding a user account to an existing group. Groups are typically organized based on job function or roles, making it easier to manage permissions for multiple users who share similar responsibilities. By adding a user to a group, they inherit the permissions associated with that group. Second is Copy Permissions: This involves duplicating the permissions settings of an existing user, including all group memberships, attached managed policies (predefined policies provided by the system), and inline policies (custom policies attached directly to the user). This can be useful when you want to replicate a user’s access for a new user with similar responsibilities. Third is Attach Policies Directly: Instead of adding policies directly to a user, it’s often considered a best practice to attach policies to a group. This centralizes policy management and makes it easier to update permissions for multiple users at once. Then, you add users to the appropriate groups to grant them the required access.

5. The last step is to Review the data you have provided and finally click on Create User.

6. Last step is we need to download a CSV file, which will include a username and password to log in to the account.

Congratulations, we have created our first IAM user in the AWS account.

Groups

Understanding IAM group

An IAM user group is a bunch of IAM users. Think of it like putting users into categories. These groups help define permissions for a group of users, which can make it easier to manage those permissions for all the users in that group.

Example: 

In the real world, different teams have different jobs and need to do different things. They should only be able to use certain things they need.

Instead of setting permissions for each person one by one, we can create groups with permissions. In AWS IAM, think of groups as teams of users. So, we can make different groups like “Admins” or “Security Auditors” and give them the right permissions.

By making groups, we can easily control what teams can do. AWS suggests making groups to manage access. This way, if you want to change what a team can do, you only need to change the group settings. It’s much simpler.

Then, we just add users to those groups. Using groups is not just easier, it’s also safer and easier to handle. For example, if someone switches teams, you only need to put them in a different group. You don’t have to redo all their permissions.

Let’s see how we can create an IAM User Group in the AWS console,

Hands-On:

1. Access “Groups” Section: In the left navigation pane, click on “Groups.”

2. Create a New Group: On the Groups page, click the “Create New Group” button.

3. Group Details:Enter a name for the group that describes its purpose or role (e.g., “Developers” or “Admins”).

4. Attach Policies: In the next step, you can attach policies to the group. These policies define the permissions the group members will have. You can search for and select managed policies (predefined policies provided by AWS) or attach custom policies. Select the policies that match the permissions required for the group.

5. Review and Create:  Review the group details and attached policies. If everything looks correct, click the  “Create Group” button.

6. Group Created: Once the group is created, you’ll see a confirmation message. You can then see the group listed on the “Groups” page.

7. Add Users to the Group: With the group created, you can now add users to the group. Click on the group’s name, and then click the “Add Users to Group” button. Select the users you want to add and proceed. Users Inherited Permissions: The users added to the group will inherit the permissions granted by the group’s attached policies.

Congratulations, we have created our first IAM user group in the AWS account.

Roles: 

Understanding IAM Role: 

An IAM role is a lot like a user, as it’s an identity with rules about what it can and can’t do in AWS. But, a role doesn’t have its own long-term credentials like passwords or access keys. Instead, when you “take on” a role, you get temporary security credentials for your role’s session. Roles aren’t just for individuals; they’re designed to be used by anyone or any service that needs those permissions (IAM users, apps, or an AWS service like EC2).

Use Roles to Share Permissions

Never put secret keys in code or on servers.

When writing code, it’s tempting to hide keys in the code itself (or in places like environment variables), but this can be risky. Even if the keys are hidden, hackers might find them. The safer way is to use IAM roles and get temporary security credentials.

You can “become” an IAM role using AWS Security Token Service (STS) or switch to a role in the AWS Management Console to get temporary access. This is more secure than using your long-term password or keys. Temporary access only lasts for a short time, which lowers the risk if your credentials get stolen.

For IAM users, make separate roles for different tasks and use those roles for those tasks. Don’t use your main IAM admin user for everyday stuff.

Roles for Apps on EC2 Instances

Apps on AWS EC2 instances need permission to use other AWS services. For example, if you have an app on an EC2 instance that needs to save things in an S3 bucket.

You could make an IAM user with keys and give those to instances. But the problem is giving keys to each instance safely, especially when AWS makes instances for you (like Spot Instances or Auto Scaling groups). You also have to update keys on each instance when you change your AWS keys.

To make apps safer, use IAM roles.

Remember: a role is like a set of rules for what’s allowed, but it’s not a user. Roles don’t have permanent keys like IAM users do. With Amazon EC2, IAM gives the instance a temporary set of keys, and these keys change automatically.

Details: Amazon EC2 uses an “instance profile” as a place for an IAM role. When you make a role with the IAM console, it makes an instance profile too. They have the same name. If you use the Amazon EC2 console to start an instance with a role or attach a role to an instance, you pick the role from a list of instance profile names. This way, apps on the EC2 instance can use the role’s keys when they talk to AWS stuff.

Let’s see how to create a Role in the AWS console:

Hands-On: 

1. Access “Roles” Section: In the left navigation pane, click on “Roles.”

2. Create a New Role: On the Roles page, click the “Create role” button.

3. Select Type of Trusted Entity: Choose the service that will use this role. This is known as the “trusted entity” that assumes the role. For example, if you want to allow an EC2 instance to access other AWS services, select “AWS service” and then choose the service that will assume the role.

Choose Use Case: Depending on the use case, you’ll select a use case that best matches your scenario. For example, if you’re granting permissions to an EC2 instance, select “EC2” from the list.

4. Permissions: Attach policies to the role that define the permissions the role will have. You can search for and select managed policies or attach custom policies.

5. Role Name: Enter a name for the role that describes its purpose or function (e.g., “EC2S3AccessRole”).

6. Review and Create: Review the role’s settings, attached policies, and trusted entities. If everything looks correct, click the “Create role” button.

Role Created: Once the role is created, you’ll see a confirmation message. You can then see the role listed on the “Roles” page.

Congratulations, we have created our first IAM Role in the AWS account.

IAM Policies 

What are IAM policies?

In AWS, controlling access is done through policies that you create and link to IAM identities (like users, groups, or roles) or AWS resources. A policy is like a tool in AWS that, when connected to an identity or resource, lays out what they’re allowed to do. The permissions stated in these policies decide if a request should be accepted or rejected.

These policies are usually saved as JSON files within AWS.

Use Ready-Made Policies from AWS

If you’re new to AWS and find it tricky to create and manage your own rules for different users and teams, you’re in luck. AWS has pre-made policies that you can use. These policies are like templates for common tasks. No matter if you’re setting up stuff or working with data, there’s likely a policy for you. Using these saves time and they even update when new stuff is added by AWS. But be careful: these policies might give more access than needed, so be cautious.

Let’s see how we can create an IAM policy in the console.

Hands-On:

1. Access “Policies” Section: In the left navigation pane, click on “Policies.”

2. Create Policy: On the Policies page, click the “Create policy” button.

3. Choose a Policy Type:

You can either create your own policy from scratch using the JSON editor (select “JSON”) or use the visual policy editor (select “Visual editor”). For simplicity, let’s choose the “Visual editor” option. In the visual editor, you can search for and select individual actions and resources, or you can attach existing managed policies. This defines what actions are allowed or denied for resources.

4. Now allow the actions on resources for service you have selected in earlier steps.

5. Review Policy:

Review the permissions and resources you’ve added to the policy. Ensure they match your intended access requirements.

6. Specify Policy Details:

Give the policy a name and optional description to help identify its purpose (e.g., “S3ReadPolicy”).

7. Review and Create: Review the policy details. If everything looks correct, click the “Create policy” button. Once the policy is created, you’ll see a confirmation message. You can then see the policy listed on the “Policies” page.

Congratulations, we have created our first IAM Policy in the AWS account.

Best Practices 

Avoid Using the Root User

Companies might create one main AWS account with powerful root credentials and then make many other users and roles with different credentials. However, the root account should always be the most protected in an AWS setup.

Never use your AWS root account’s special key to make requests to AWS. This key gives unlimited access to all your stuff across AWS services. You can’t limit its permissions. So, treat your root account’s special key like super secret info. Just as you’d protect your credit card details, keep the root key safe. Here’s how:

Don’t use the root user for normal tasks, even important ones. Only use the root account to make your main IAM admin user. After that, lock the root user away safely. For everyday tasks, don’t even use your IAM admin user. Use roles to share permissions. Delete the root user’s special key. Or if you must keep it (but you don’t really need to), change the key regularly.

Add Extra Security with Multi-Factor Authentication (MFA)

MFA adds a second safety step based on something you have, like a special device. It’s a great idea to turn on MFA for all users in your AWS account. With MFA, even if someone gets your password or keys, they can’t get into your stuff without that extra thing (like a code from a device).

Use Strong Password Rules

If you let users change their own passwords, set rules that make them create strong passwords, and switch them up sometimes. You can make IAM admins set rules that need users to have strong passwords and change them regularly. Strong passwords are harder to guess, making your cloud stuff safer.

Choose IAM Roles Over Long-Term Keys

Keys give long-lasting access to AWS. If they’re stolen, it’s like giving away your account password. For most apps that need AWS access, it’s better to make them use a special role to get temporary access. Also, don’t leave keys in plain code. Use secrets instead. Don’t share these secrets between users. Each user should have their own keys.

Keep Changing Credentials

If someone steals your password or keys without you knowing, they can use them forever. Change them regularly to cut that risk. If you make all your users change their passwords often, even if a credential is stolen, it’s only useful for a short time.

Get Rid of Old, Unneeded Credentials

If you made a user just for a job that doesn’t use the console, that user doesn’t need a password. If a user only uses the console, take away their keys. Also, find and delete unused passwords and keys to boost security. You can do this using the console, command line, or API, or by checking a credentials report

Customer-Made Policies Are Safer

While the pre-made policies are handy, they don’t always follow the safest route. To be super safe, create your own policies. These should only give the exact permissions your team needs. But, this needs more effort. You also need a way for your team to ask for more permissions if needed.

Usually, it’s better to use customer-made policies over inline ones (policies attached directly to users or groups). Customer-made policies can be used for many users, have better change control, versioning, and let you share permissions control.

More Security: Set Conditions

Security needs context. You can add conditions to your policies, like allowing access only from specific places or needing an MFA device. But don’t make it too complicated.

Check and Validate Policies

Check your policies to make sure they’re correct and logical. Most text editors can do this easily. For even better policies, use tools like IAM Access Analyzer to check for security risks and get suggestions for safer policies.

Create Policies Based on Activity

This is smart: If you’re not sure what’s used where, but want to keep things safe, you can generate policies based on what’s been used before. Using your AWS CloudTrail logs, tools can make policy templates that show exactly what’s needed. Attach these to users or roles, and you’re good to go.

Review and Fine-Tune Access Levels

Keep checking your policies to make sure they’re safe. Policies are categorised based on what they let you do: list, read, write, manage permissions, or add tags. Make sure to use the right level for each task.

Conclusion

Overall, IAM is like a superhero for AWS security. It helps you to manage who can do what in your AWS world. By using user groups, roles, and policies, you can control access in a smart way.

Remember, it’s important to be careful with access keys and passwords. Instead of giving too much power to one person, it’s better to use roles and groups to share permissions. And always make sure to use strong passwords and change them sometimes.

IAM makes AWS safer and organised. Following these tips will help you build a strong shield of security for your AWS resources.

Read a related article here: Empowering Non-AWS Workloads With AWS IAM Roles For Secure Access

Checkout our Online AWS Courses