AWS IAM 101

Getting Certified

I’m in the process of getting AWS certified and currently preparing for AWS Solution Architect Associate. Although lots of online training resources are available, the learning materials are not that refined to my taste. During my whole education life, I learned by writing in my words, learning by teaching to myself. That’s why I decided to write a series of posts for me and hopefully I hope other AWS Beginners will benefit. Let’s start!

Photo by Brett Jordan on Unsplash

IAM: Who are you?

IAM is the very first service that welcomes you every time you login to the Management Console. IAM validates your identity, limits your access based on your permissions.

IAM stands for Identity and Access Management.

Root User

When you create your AWS account, it is a deserted place. It is only you who created the account there. You’re called the “Root User”.

So lonely Root User

• Creator of the AWS account is called “Root User”.
• Unlike other users, root user logins with an email address instead of a username.
  Also they aren’t required to provide an Account ID.
• Like in Linux, the root user has access to everything.
• Great power comes with great responsibility.
  Even if you’re the only one in your organization, it is strongly advised to create an IAM user and not to use root user during day-to-day activities.
• It is recommended to enable Multi-Factor Authentication for root users.

Photo by Felicia Buitenwerf on Unsplash

IAM User

• In order to interact with any service of AWS, you need an IAM User first.
  In fact the above statement is technically incorrect, you can continue using your root user but it will be very insecure to do so.
• IAM User logins to the Management Console with the Account ID, Username and Password.
• You can also enable Multi-Factor Authentication for IAM users as well. It is recommended by AWS indeed.
• If you want to use programmatic access such as AWS CLI and AWS SDK, you need to generate Access Keys.
  An Access Key is composed of an Access Key Id and Secret Access Key similar to a username and password. You need to store it safely like a password because it provides long-term access to AWS.
• IAM User does not always need to be a real person but it can also be an on-premise application that needs access to AWS services.
• By default, an IAM User has NO permissions.

From what we learned so far, the picture of IAM service looks like the diagram below. Until now, we’ve answered the question “Who?” and revealed the “I”dentity in IAM.

Root User and IAM Users in an AWS Account

Photo by Matt Seymour on Unsplash

IAM Policies

Now let’s answer “What?” or the “A”ccess in IAM. As mentioned above, all IAM users can NOT take any action by “default”. They’ve NO permissions. You, as the Root User, have to grant permissions to the IAM Users. IAM Policies come into picture at this stage.

Basically, an IAM Policy is a collection of statements that allows IAM Users to take specific actions on AWS resources. IAM Policies are defined as JSON documents. Below is a simple IAM Policy JSON document example.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

Above policy document grants all actions to be taken on all resources of the famous S3 service. Each statement has following required elements,

• Effect: The Allow value obviously grants permissions. There is also Deny value which is also self-explanatory. If an IAM User has been associated with both of them then Deny always takes precedence over Allow.
• Action: The Action value has two components: service namespace and action. Service namespace is a prefix in the action like s3 in the above example.
  Following service namespace after “:” colon, the action can be specified. Please note that each service has its own set of actions.
  You can use wildcards in the action component. Above example grants all actions for the S3 service.
  In addition, you can simply just use “*” without any action component. This will grant all actions for all services.
• Resource: In the AWS universe, each resource has a unique Amazon Resource Name (ARN). A resource can either reference to a specific resource by the exact ARN or reference to a group of resources by using wildcards.

You need to learn the above elements by heart for exams. Recall from mnemonic “EAR” for Effect, Action, Resource.

Multiple IAM Policies assigned to Users

Multiple IAM Policies can be assigned to a single IAM User. Also a single IAM Policy can be assigned to multiple IAM Users.

Before going further, it is important to mention that there are different kinds of policies.

1. AWS Managed Policies: General purpose, ready-to-user policies that are created and maintained by AWS.
2. Customer Managed Policies: Use-case specific policies that are created and maintained by you.

There is another kind of policy called Inline Policy. It is not recommended to use it anymore due to its non-reusable nature. It is kept for backward-compatibility.

Least Privilege Principle

When you’re assigning IAM Policies to users, you should be ungenerous. You should grant only the permissions to accomplish the required tasks but not more. This is called Least Privilege Principle.

Photo by Hannah Busing on Unsplash

User Groups

The above setup works well until your company scales. Sooner or later, you’ll find yourself attaching and removing IAM policies from many users. It will be very time-consuming to maintain such a setup. “User Groups” come to rescue. You can create “User Groups” such as “Developers”. You can add all your DEV users to the “Developers” and manage permissions (policies) only within the group. Accordingly, you can simplify permissions management.

Moreover, if you’ve some staff that wear multiple hats, you can add him/her to multiple groups as you’d like. Users will inherit all permissions from his/her groups cumulatively.

Jane is a member of both Administrators and Developers User Groups.

Please note that a “User Group” can contain only IAM Users but not any other user groups. e.g., you can NOT create a user group called “DevOps” and attach the “Developers” and “Administrators” user groups to it. You need to manually maintain such IAM Users with multiple groups like in the example user Jane above.

Photo by Eduardo Pastor on Unsplash

Roles

Well, this is where things are really complex and hard to grasp. IAM Roles have multiple use-cases and it will be difficult to digest them in one go. Let’s start with a simple example.

Suppose that your company decided to migrate your on-premise application to AWS EC2. As the application was already utilizing AWS services, you created an IAM User and stored your access keys in the application. Well, technically you can go ahead and deploy your application to an EC2 instance and it will work as-is.

However, this is a bad security practice. You should NOT store long term credentials in your EC2 instance. Instead you can assign an IAM Role to the EC2 instance and delete your access keys. Magically, your application will continue working fine. Your EC2 instance will “assume” the IAM Role and be granted the permissions.

So, what’s an IAM Role?

Think of an IAM Role similar to an IAM User.

Like an IAM User, it is an “identity” and you can assign IAM Policies to an IAM Role as well.

Unlike an IAM User which is associated uniquely with one person or application, IAM Roles can be associated with multiple people, applications, and more.

IAM Roles does not have long-term credentials like passwords and access keys. When an IAM Roles is assumed, a short-term credential (token) is provided.

Other use-cases to an IAM Role are as follows. Please note that there are other use-cases as well.

1. AWS Service Roles
   Use AWS Service Roles when you need to grant an AWS Service to take actions in your account on behalf of you. For the example above, we need this kind of IAM Role.
2. Identity Federation
   If you run a medium-sized company, you probably maintain an Identity Server. Why not make use of your Identity Server and get rid of maintaining IAM Users for your employees. By setting up Identity Federation, you can grant your users access to AWS.
3. Cross-Account Access
   Even small companies tend to own multiple AWS Accounts. Even more, you may need to partner with other companies to grant access to your AWS resources. In this case, you can make use of IAM Roles as well.

Photo by Louis Hansel on Unsplash

IAM Security Tools

IAM may get complex to manage but it is also very important to secure your account. Hopefully, AWS is offering tools to ease out our work.

IAM Credentials Report

IAM Credentials Report provides a list of your users along with the availability of passwords, access keys, MFA and their last usage,

IAM Access Advisor

If you want to achieve “Least Privilege Principle” mentioned above, you need to track users for grant permissions that are not used anymore. IAM Access Advisor is able to report the last used time per policies and services. Accordingly, as an administrator you can revoke unused policies from users.

IAM Access Analyzer

IAM Access Analyzer (IAM AA) can do three things for you,

1. Reactive: IAM AA helps you to identify resources that are shared publicly or with an external entity. I call this “Reactive” functionality of IAM AA.
   e.g. Public S3 Buckets that are supposed to be private is a common error. IAM AA helps you spot such problems.
2. Proactive: IAM AA helps to validate IAM policies against security best practices. Before deploying a policy, IAM AA warns you about errors, security warnings and provides suggestions. I call this “Proactive” functionality of IAM AA.
3. Advisor: You’ve have IAM Access Advisor to check the permissions that are not used. However it is simply a report and you still need to do the hard work to refine policies. IAM AA can generate an IAM Policy based on the access activity for you. Sorry, IAM Access Advisor, this is what an advisor is meant to do. I call this “Advisor” functionality of IAM AA.

Photo by Brett Jordan on Unsplash

IAM Best Practices

Security is a continuous effort. If you want to keep your AWS Account safe, don’t forget to keep below advice.

• Safeguard your root user account and don’t use it.
• Require MFA for all human users.
• Create a strong password policy.
• Apply least-privilege permissions.
• Don’t share users.
• Use Audit Tools regularly.
• Keep Access Keys secret like passwords and rotate them regularly.
• For workloads such as EC2, always use IAM Roles.

Photo by Markus Spiske on Unsplash

Conclusion

When I decided to write this article, I never thought this would be so long. AWS is not that simple, so IAM. Anyway, this is a solid foundation to IAM Service.

I put an enormous effort into completing this article. If you’d like me to continue this series, please don’t hesitate to like and follow me. I also liked to hear from you in the comments if you notice anything incorrect or confusing.