Create IAM User, Group, Roles & Policy

Introduction:

Welcome to the first hands-on blog of our "Mastering AWS DevOps" series! As you dive into Chapter 4 of the book, this post will provide practical, step-by-step instructions on creating and managing IAM users, groups, roles, and policies in AWS. This is a foundational skill for any AWS DevOps professional, as effective IAM (Identity and Access Management) is crucial for securing your AWS environment and ensuring that users have appropriate access to resources.

In this blog, you will learn:

• Creating IAM Users: How to set up new users and securely manage their access keys and passwords.
• Defining IAM Groups: The importance of groups for managing user permissions collectively.
• Establishing IAM Roles: When and how to use roles to delegate access across different AWS services and accounts.
• Crafting IAM Policies: Writing and applying policies to enforce fine-grained permissions for users, groups, and roles.

Our approach combines timeless AWS DevOps concepts with up-to-date, practical instructions. While the book provides the theoretical background, this blog offers hands-on guidance, ensuring you can apply what you’ve learned effectively.

AWS Identity and Access Management (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.

IAM has two main roles:

1. Proving Who You Are (Authentication):

   This is similar to showing an ID before entering the office premises. 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.

2. Deciding What’s Allowed (Authorization):

   Simply getting inside office premises doesn’t mean you can do everything. Some might be restricted or have specific rules. Same in AWS, 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.

Now, let's understand the three main IAM identities:

• IAM Users: AWS IAM allows you to create individual user accounts associated with your AWS account. Each user has a unique set of security credentials and specific permissions. Users are used to authenticate and interact with AWS services.
• IAM Groups: Instead of assigning permissions to individual users, you can organize users into groups and then assign permissions to the groups. Take the example of a Development team or Administration team. So all people in these teams need the same level of permission. This makes it easier to manage permissions for multiple users who require similar access.
• IAM Roles: IAM roles are similar to users, but they are not associated with a specific person. Roles are meant to be assumed by entities such as AWS services, applications, or users from other or the same AWS accounts. Roles define a set of permissions, and users or resources can assume these roles temporarily.

IAM ensures that the right people use the right things in the right way in AWS by managing these identities effectively.

Creating IAM Users: How to set up new users and securely manage their access keys and passwords.

To create a user, follow these steps:

Step 1: Login to the AWS console and you will be on the console home page. Here you have to search IAM (Identity and Access Management) and you will be navigated to the IAM dashboard. On the left side, you will get options like user groups, users, Roles, and Policies. Etc. (Figure 1.2.1 IAM Dashboard and Figure 1.2.2 IAM Dashboard)

Step 2: We are creating a user for our account. Click on users and on the right side you will see there is a button Create user. Click on that button. (Figure 1.3.1 Select users and Figure 1.3.2 Create User)

Step 3: Now we have to give a username, if you want to grant this user console access, select the checkbox. (Figure 1.4.1 Specify user details)

Step 4: When you click the checkbox, you will have 2 options: 1) Specify a user in the identity center-Recommended. 2) I want to create an IAM user. Here you will select 2nd option. (Figure 1.4.2 Recommended and Figure 1.4.3 Create an IAM user)

Step 5: After that, create a password for this user. You have two options for the password:

• Automatically generate a password by selecting the first option.
• Customize the password by selecting the second option, as shown in the image.

Once you've made your choices, click on the next button. (Figure 1.4.4 Custom password)

Step 6: Then, you can see three options:

1. 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.
2. 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.
3. Attach Policies Directly: Instead of adding policies directly to a user, attaching policies to a group is often considered a best practice. This centralizes policy management and makes updating permissions for multiple users at once easier. Then, you add users to the appropriate groups to grant them the required access.

Click on the Next button.(Figure 1.5 Set permissions)

Step 7: Now you can check whether all fields are filled correctly or not, you can edit here if you want to change anything. Click on Create User. (Figure 1.6 Review and create)

Step 8: The last step is to download a CSV file, which will include a username and password to log in to the account. Congratulations, you have created your first IAM user in the AWS account. (Figure 1.7 User-created)

Defining IAM Groups: The importance of groups for managing user permissions collectively.

Understanding IAM Group

An IAM user group is a collection of IAM users, organized to facilitate the management of permissions for a group of users. Think of it as categorizing users into specific groups, making it easier to handle and define permissions.

For Instance: In the real world, different teams have distinct roles and responsibilities. They should only have access to the resources and actions they require.

Instead of individually setting permissions for each person, groups with predefined permissions can be created. In AWS IAM, consider groups as teams of users. For instance, creating groups like "Admins" or "Security Auditors" allows for the assignment of appropriate permissions to those teams.

By using groups, access management becomes more straightforward. AWS recommends using groups to organise access, making it easier to modify team permissions. If you need to change what a team can do, you only need to adjust the group settings.

Furthermore, users can be added or removed from groups, simplifying the management process. For instance, if someone switches teams, you only need to place them in a different group, eliminating the need to redo all their permissions.

Let’s start:

Step 9: Go to the IAM Dashboard and in the left navigation panel, click on User Groups. (Figure 1.8 Select User Groups)

Step 10: You will be navigating to the User group page, On the right side there will be a button Create group. Click on Create group. (Figure 1.9 Create group page).

Step 11: On this page, you have to fill up the group details, and enter a name for the group that describes its purpose or role (e.g., “Developers” or “Admins”).(Figure 1.10 User Group details)

Step 12: 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.

Review the group details and attached policies. If everything looks correct, click the "Create Group" button.(Figure 1.11 User Group created)

Once the group is created, you’ll see a confirmation message on top of the page. You can then find the group listed on the “Groups” page.

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.

The users added to the group will inherit the permissions granted by the group’s attached policies.

Establishing IAM Roles: When and how to use roles to delegate access across different AWS services and accounts.

Understanding IAM Role: An IAM role is similar to a user, serving as an identity with defined rules for actions within AWS. However, a role doesn’t have its long-term credentials like passwords or access keys. Instead, when you “take on” a role, you receive temporary security credentials for your role’s session. Roles are not restricted to individuals; they are designed to be utilized by anyone or any service requiring specific permissions (IAM users, applications, or AWS services like EC2). (Figure 1.12 Role)

Use Roles to Share Permissions

Alert: 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 of your credentials getting 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 start:

Step 13: Go to the IAM dashboard and on the left side panel you will find the option Roles. Click on Roles (Figure 1.13 Select Roles)

Step 14: On the Roles page , you will find a button create role. Click on Create role. (Figure 1.14 Create role)

Step 15: You will be navigated to select trusted entity page. Here you will get 2 options.

1. 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.
2. 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.

After selecting both fields click on the Next button.(Figure 1.15 Select trusted entity)

Step 16: 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 and click on the Next button. (Figure 1.16 Add permissions)

Step 17: Enter a name for the role that describes its purpose or function (e.g., “EC2S3AccessRole”) (Figure 1.17 Name, review and create)

Step 18: Review the role’s settings, attached policies, and trusted entities. If everything looks correct, click the Create role button. (Figure 1.18 Create role button)

Step 19: Once the role is created, you’ll see a confirmation message. You can then find the role listed on the “Roles” page. (Figure 1.19 Roles created)

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

Crafting IAM Policies: Writing and applying policies to enforce fine-grained permissions for users, groups, and roles.

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 start:

Step 20: Go to the IAM dashboard and now select policies in the navigation panel.(Figure 1.20 Select policies)

Step 21: On the Policies page, click on the Create Policy button.(Figure 1.21 Create policy)

Step 22: 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. (Figure 1.22 Specify permissions)

Step 23: Now allow the actions on resources for the service you have selected in earlier steps. Click on the Next button. (Figure 1.23 CodeDeploy)

Step 24: Review the permissions and resources you’ve added to the policy. Ensure they match your intended access requirements. Give the policy a name and optional description to help identify its purpose (e.g., “S3ReadPolicy”). Click on Create Policy. (Figure 1.24 Review and create)

Step 25: Congratulations, we have created our first IAM Policy in the AWS account. (Figure 1.25 Created IAM Policy)

Best Practices

Avoid Using the Root Use

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:

1. 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.
2. For everyday tasks, don’t even use your IAM admin user. Use roles to share permissions.
3. 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, and 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 categorized 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 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 organized. Following these tips will help you build a strong shield of security for your AWS resources.

Share this post: