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 an existing or new setup. Let’s jump into these approaches and discuss them 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 catch to it. There is always a quota to everything in AWS, including attachment of policies to a user. It can be found in the official documentation, which states that we can only attach 10 IAM policies (including both AWS managed and customer managed policy) directly to a user which is not a scalable solution.
- Increase quota of managed policy
- Using group
- 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.
We can use IAM groups to 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.
IAM groups solve our problem to a good extent, but we are still going to hit a limit sooner or later as we scale out. AWS provides us with one more option, inline policy. It is basically another type of policy. It can be considered a life saver for those who want to attach a large amount of 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 policies are 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, over time 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 and policies per environment separately.
AWS groups are not mainly for solving quota problems but for separating users on the basis of tasks, environments, and teams.
It’s important to note 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 visualize 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 visualize 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 (_)
- 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 visualize or track information on cloudwatch on the basis environment, types, etc.
For AWS IAM, we can use tags to filter out policies, users, roles and 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” and “value” part as well - 128 characters for the key part and 256 characters for the value part.
- 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 groups are very effective for multiple cases like quota issues and 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 and managing IAM options.
- Tag is also one of a kind that can be used to track and manage IAM options.
- Both IAM options, name and tags, have a limit.
This is just the beginning with some basic approaches which we felt we should start with and yes, there are even more advanced approaches 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. Until then, wait for the next blog with more advance and useful approaches.
Opstree is an End to End DevOps solution provider.