AWS IAM: Best practices [Part 1]

In the last blog, we talked about why proper management is important for AWS IAM which is not only related to security but also paves an appropriate way of handling things.

Now we’ll discuss some approaches to manage IAM, how these approaches/practices will affect access management and by using an example, we will also discuss how we can include these practices in the existing or new setup. Let’s jump into these approaches and discuss these practices one by one.

Best practices / Approaches

If you are new to IAM or this is your first post in our AWS IAM blog series, please checkout previous AWS IAM: the challenge blog for better understanding the context and to know why we need a better approach to managing AWS IAM and what are the components/choices that AWS IAM provides.

In this post, we will discuss a few approaches. They are not mandatory but can be followed to build from scratch or improve existing practices.

• Attaching IAM policy directly to the IAM user is not a good practice

We can attach IAM policies directly to an IAM user but there is a twist to it. If we consider AWS quota, there is always a limit to everything including attachment of policies to a user. It can be found in the official documentation here, which states that we can only attach 10 managed policies (including both AWS defined & custom managed policy) directly to a user which is not a proper solution.

Solutions:

1. Increase quota of managed policy
2. Using group
3. Inline policy

Increase quota of attaching managed policy per user:

This is not a proper solution because we can only increase managed policy attachment up to 20 by raising support tickets (current maximum quota allowed as per official documentation) and what would happen when we need more policy attachments than the maximum allowed number? It can help in some way but it’s still not a proper method of setting up policies with IAM users due to its limits.

Using group:

When we attach IAM policies directly to an IAM user, we are unable to optimize the setup because of the quota limit. If we increase the quota by even 10, it will give a total of 20 policy attachment to a specific IAM user. To overcome this problem, we can use IAM groups which can solve this problem because we can attach IAM users to multiple IAM groups and groups can support up to 10 policy attachment each. So, by calculation, we can confirm that we can use or attach more than 10 policies to an IAM user.

Inline policy:

IAM groups solve our problem to a good extent still we are going to hit a limit in the above solution sooner or later. It depends on the scale of our implementation. Therefore, AWS provides us with one more option, inline policy. It is basically another type of policy. It can be considered as a life saviour for those who want to attach uncountable policies to a specific IAM resource like roles, group or users.

But we have some limitation here as well. We cannot inherit inline policy from one IAM resource to another. In other words, inline policy is bound to an IAM resource and cannot be used by another. Hence, the scope of inline policy is limited to its IAM resource (roles/group/users).

In our upcoming blog series, we will also discuss different policy types and also consider their use-case and how each policy type solves day to day issues.

• Group based approach

If we ignore IAM quota issues for sometime, we will see that attaching IAM policies directly to users can make things complicated. Why is it so? Let’s consider an example where we want to revoke or add any specific policy from/to multiple users of an environment. Here, we will have to perform the operation on all the IAM users individually. One more thing, we have to keep a record of users & policies per environment separately.

AWS group is not mainly for solving quota problems but for separating users on the basis of tasks, environments, and teams.

It’s important to know that groups also have a default policy attachment limit of 10 and one IAM user can only be attached to 10 groups by default.

• Naming convention while creating IAM policies/group/roles.

Name-based approach is not a feature or option in IAM but a convention. Using this we can easily distribute IAM resources on the basis of environment, teams, types and duration.

If we don’t use any naming convention or don’t follow a proper naming format, we cannot visualise or track policies on the basis of their names. Say, we want to create two policies having the same use-case but separate teams and environment. Not having a convention won’t tell us anything about the policy as to which environment it belongs to, what permission it contains, if it is temporary or not, etc.

The above diagram illustrates only one part of IAM policy, if we will not provide enough values to IAM policy name, we will find it hard to keep track. Another option is to look into the actual JSON content of each policy which will be a long and tedious process.

Using naming convention, we can easily filter out or visualise any kind of policy that we create. Let’s take an example, we want to create two policies and both policies are doing exactly the same thing [ ex. – access EC2 servers ] but one of the policy is for the prod environment and another one is for the QA environment. Another example is when we are creating policies on the basis of timestamp or for a short duration [temporary] of time, then we can use naming convention to provide date-time and if possible “temp” part in IAM policy name. There are plenty of examples where we can use this naming convention which gives us much flexibility to track and monitor policies on the basis of name.

There are limitations here as well, the official documentation states that we can use 128 characters for the AWS IAM policy name. The name must be alphanumeric, including the following common characters: plus (+), equal (=), comma (,), period (.), at (@), underscore (_), and hyphen (-).

This naming convention is not only for policies but we can follow this approach for multiple AWS IAM resources like roles, group and for users also.

• Tag based approach

Tags, which are a part of metadata also known as key-value pair of any given resource, are a very powerful option of any resource and used in many ways. Tags in AWS resource provides flexibility to filter out the services on the basis of key-value. It is also used to visualise or track information on cloudwatch on the basis environment, types, etc.

For AWS IAM, we can use tags to filter out policies, users, roles & groups etc. If someone doesn’t want to follow the naming convention approach for AWS IAM resources, they can use this tag-based approach which is provided by IAM itself to provide metadata related to environments, types, duration, team etc.

There is a limitation to this tag-based approach also. There are only 50 tags allowed per IAM resource which means we can create 50 key-value pair for each group. There is a word limit for both the “key” & “value” part as well. 128 characters for the key part and 256 characters for the value part.

Summary

• We should not attach policies directly to IAM user because of the quota limit.
• Increasing IAM policy attaching quota is not a proper approach or solution for directly attaching policies to IAM user.
• IAM group is very effective for multiple cases like quota issue & to distinguish on the basis of their types.
• The Inline policy is very effective but its scope is only within the IAM option.
• Naming conventions is very good for tracking & managing IAM options.
• Tag is also one of a kind that can be used to track & manage IAM options.
• Both IAM options name & tags have a limit.

Conclusion

This is just the beginning with some basic approaches which we felt that we should start with and yes, there are even more advanced approaches that we can follow for access management.

These approaches are not mandatory and some of them are not even part of AWS IAM but I find them useful and effective. We can use them in our existing as well as new access management practices for AWS.

Let us know about your experience related to IAM in the comment section and how you manage things to get the best out of it. Till then, wait for the next blog with more advance and useful approaches.

GIF reference

Blog Pundit:  Kapendra Singh & Adeel Ahmad

Opstree is an End to End DevOps solution provider