Best Practices for Cloud Security with AWS IAM: Managing Groups, Policies, and Roles

Tanmoy Santra
5 min readApr 20, 2023

--

Let's learn about cloud security in AWS. How big organizations maintain and secure their cloud (AWS).

This is what the AWS IAM dashboard looks like. From here we can maintain everything.

IAM basic Architecture

We should not use the root account for our day-to-day tasks. If you're using the root account you should know why you are using the root account.

Always we should create an IAM user account for our daily tasks. Because when we create an IAM user account there is no permission to do anything. We can't do anything until we give particular permission, for what we are trying to do.

Here we created our new user test-user. Now we want to give permission to this user, we need to add policies to this account. Because using policies we can give whatever permission we want to give.

Let's give him permission and let's see how can we create policies to give permission.

We can attach policies, that AWS created. There are several policies AWS created, that every time anyone doesn't need to create their own policy. Just attaching a policy can solve their issue.

We can simply choose a policy from here(as per our requirements) and attach it to the IAM user.

Or we can create our own policy and attach it to the IAM user.

Here we created a policy where we are giving list (all), read(all), and write(all) permission.

One more thing to notice here, some warning is showing here. This is the best part, after creating a policy you can check the policy JSON. And it will give you an error if there is any issue.

Here our issue is our policy got more character than its limit(10240). For solving this we need to part it in 2 or we can say, we need to separate this policy into 2 politics.

One more thing I want to add, we can also use the AWS policy generator and generate our policies manually and merge them later on.

Link — https://awspolicygen.s3.amazonaws.com/policygen.html

Now we understand that best practices are creating individual accounts and attaching the policy as it needs.

Okay, but we have a team of 10 developers who are using RDS and they need read-write permissions. So we will create each individual IAM user account and give them permission by creating 10 individual policies?

For solving this problem we have User groups. We can create a Developer group and add those 10 developers to this group.

And we can attach policies as the requirements. (we can see our custom-created policies and AWS-created policies both here.)

d

In organizations, they maintain this same way. They create different User groups for different teams(Developer, DevOps, Operation and add IAM users according to it.)

But what if someone in the developer group needs to give AWS DynamoDB permission but other developers don't need this permission?

Then we can add the DaynamoDB policy only to that developer ( we will not add this policy to the User group).

More questions are there, we are not using the root account, and everyone has only permission to do their required things. Then who is giving the permission? From which account permission can be attached?

If someone gets the IAMFullAccess policy attached to their account they can manage, and change everything to every IAM in this AWS account.

But in general, organizations maintain an admin IAM account. This IAM user account is managed by Architects or higher authorities. (Someone who has the experience to manage all of these things)

After attaching the AdministratorAccess policy admin account get all permission.

One more thing is there, IAM Roles.

Using IAM Roles we also can give permission to someone to use our account. Then what is the difference between IAM user and IAM roles?

IAM users are intended for long-term access and are often associated with human users, such as employees or contractors, or applications that require continuous access to AWS resources and services. IAM users are granted permissions by attaching policies directly to the user, which defines what actions the user can perform on which resources.

On the other hand, IAM roles are intended for temporary access and are often used by AWS services, applications, or other AWS accounts to access resources in a secure and controlled way. IAM roles are granted permissions by attaching policies to the role, which define what actions the entity that assumes the role can perform on which resources.

In summary, IAM users and IAM roles serve different purposes in AWS IAM. IAM users are intended for long-term access to AWS resources and services, while IAM roles are intended for temporary access by trusted entities. Both IAM users and IAM roles are important tools in AWS IAM for managing permissions and access to AWS resources and services.

Thank you for reading this blog. Follow me for the next blog on DevOps project using GitOps.

--

--

Tanmoy Santra

Engineering @Adda247 | Writing about Software Engineering, Backend, Architecture, and Cloud. Linkedin - https://www.linkedin.com/in/tanmoy-santra/