AWS has a plethora of services under its hood. Among them, one of the critical services that every developer should be familiar with is AWS IAM - Identity and Access Management. This service was initially launched in May 2011 and features were built incrementally to make it the primary identity system to use the AWS cloud platform and its services.
Yes, IAM is one of the crucial components of AWS.
Learning and understanding about IAM helps us to have a better understanding of how AWS handles its resources in an effective, safe, and secure manner.
Before learning about IAM and its features, let's have a solid understanding of Authentication and Authorization.
In software applications, maintaining the security of the system is highly important. Both Authentication and Authorization are fundamental aspects of security for the software system that we want to build.
Authentication is the process of determining the identity of the user who is currently accessing the software system. Authorization on the other hand is the process of checking the permissions/rights of the user who is accessing the resources of the software system.
Authentication can be performed in multiple ways. One standard way of doing this is a username and password combination which we all use day-to-day. Authorization on the other hand also happens daily like a user is allowed to access a certain webpage or not.
Do note that authentication always happens before the authorization. The user’s privileges, permissions, or access rights cannot be determined before the user has logged in to the system.
Examples of Authentication are Username and password Auth, Passwordless Auth, 2FA or MFA (Multi-Factor Authentication), SSO (Single Sign-On), and so on.
Examples of Authorization are JWT (JSON Web Token Authorization), RBAC (Role Based Access), OpenID, OAuth, and so on.
IAM stands for Identity and Access Management in AWS. It is one of the primary web services in AWS which helps to securely access and control the AWS resources.
When a person signs up for an AWS account for the first time, the created account is called the Root Account. This is the primary account of the user where they can manage all the secure controls and overall cloud platform management. It is a best practice not to use this root account to perform non-important activities.
From this root account, we can create multiple user accounts (via the IAM service) to perform the desired actions on the cloud platform and its services. Usually in big enterprises, IAM accounts will be managed by a team of administrators who provide access to the users only on a required or need-to-know basis.
A person should know only things that they should know!
IAM is also a global service in AWS which means that it is common across all regions in AWS. Yes, AWS has multiple regions 😃 (which we shall explore and learn about in future articles)
Here is the official documentation link to learn more about AWS IAM.
Let’s take a step back again to understand the importance of IAM. It is a crucial component of AWS's security infrastructure, and there are several compelling reasons why you would want to use AWS IAM.
Granular Access Control of your AWS environment.
Security for all environments, applications, and the data itself.
Compliance out of the box to abide by the standards and regulations.
Identity Federation features can help to integrate with any system to perform user management or act as an identity provider for your software system.
IAM provides out-of-the-box monitoring and auditing for all the activities performed on the platform by every user.
When your organization grows in size, the infrastructure also has to grow. Managing users at scale is one of the prime features provided by IAM.
IAM is used behind the scenes when you want to access the AWS platform or any AWS service. There are 3 different ways by which we can access the platform. In all these ways we have to authenticate and authorize with IAM service which acts as the entry point or guardrail for the system.
AWS Management Console is the web-based interface where the users can access cloud resources. Usually, this will be IAM user login and password-based.
NOTE: AWS also supports MFA which means Multi-factor Authentication via different authentication mechanisms. It can be either a digital token generator app or a physical identity token generator.
The next way is AWS CLI where the IAM users can access the resources. Since this is CLI-based it will be used by the pro users who know to work with the CLI.
To work with AWS CLI, we will need the access key and secret for that particular IAM user. So when we want to set up the console,
aws configure command follows standard step-by-step instructions which help us to generate these credentials so that we don’t have to type the username and password every time. It can also be directly generated from the IAM page in the Management Console.
The Access Key is similar to the username and the Secret access key is similar to the password. We should always safeguard this information and provide high importance as we do for our general login credentials.
NOTE: If any of the unknown person has access to these keys, then they might use these to access your cloud platform and finally you might end up with a huge bill from AWS. It is the user’s responsibility to safeguard these keys.
AWS SDK is another way of accessing cloud resources. These are built and provided by AWS and it supports different languages and platforms. These SDKs will be used by those developers to write software and perform certain actions in the platform via code. SDKs are used at the application level and hence authentication and authorization are a must at this level too. It can be done using the same access key and secret generated for the IAM user.
There are a few keywords that we have to understand to get a better understanding of how IAM works in general.
Users. Yes, users are people like us who work in a project or company. Users are those people who belong to your organization. Users are the first class citizens in IAM and are considered to be the primary entity.
A group is nothing but a collection of users. They can be developers, testers, finance personnel, admin, etc. Multiple users come together to form a group. Users can belong to a single group or multiple groups. Yes, I am talking about that one critical resource in your team who is the developer, tester, and admin. LOL 😂
Roles can be defined as the standard assigned definition for a user or an AWS service to perform allowed actions on the AWS platform. Mostly it will be those automated cases where one of the AWS services assumes a standard role to perform some actions on another AWS service.
A few of the examples related to AWS roles are mentioned below,
A lambda function with a designated role to read objects present in a specific S3 bucket
An EC2 instance with a standard role to access another EC2 instance present in a different AWS region
Policy is a very simple concept to understand yet it can be complicated to write. These are JSON documents that contain all the permissions and rules. These policies can be assigned to a single user, a group of users, or even for an IAM role that is assigned to a user.
Policies are the standard set of instructions that are written in the form of JSON for AWS to understand who can access what in a standard way.
Let’s break down the syntax step by step,
Version - This is the version of the policy document that AWS maintains and understands. Let’s not touch this. This is a required property.
Id - An identifier for the policy that we are crafting. This is an optional field.
Statement - This is a required field. There can be one or more statements in a single policy. In the above example, there is only one statement called
- Sid - This is the user-defined identifier for the policy statement. It can be anything as long as it makes sense and is understandable by your team members. Note this is an optional field.
- Effect - It can either Allow or Deny.
Principal - Account or the User for this policy applies to. In the above example, it applies to
batman😰 I mean
Action - This field describes the actions which can be performed. It can be a list of actions or a single action. This should follow the standard syntax statements as defined by AWS. In the above example, it says
s3:*which means all actions are allowed on the S3 service.
- Resource - This field refers to the list of resources this policy statement is applicable. Again this can specified to a granular level if needed.
So overall to explain the policy in a single sentence,
bruce-wayne is allowed to perform any action on the S3 service on all resources
Policy documents can be as complex as we want them. It can be nested with multiple statements to have fine-grained control of our resources in AWS.
NOTE: There are several AWS-defined policy documents already available which is more than what we need. Usually, these fine-grained policies will be crafted based on the user’s needs but for learning purposes, you can always use the pre-defined policy documents.
AWS also provides a live policy editor which can be done easily from UI that shows which permission the user has or not. In this editor, the JSON document can edited live both in raw JSON format or visual format with a long list of checkboxes.
Ultimately what matters is,
The users should have permission to do only what they need rather than everything - The principle of least privilege.
Do not provide access to anything and everything.
Monitor the usage pattern of the users in your organization or project to understand the necessary permission for the users and fine-tune the parameters in the IAM service.
AWS always stresses the shared responsibility model which means both AWS and users have responsibility in maintaining the security of the cloud platform.
AWS is responsible for maintaining the infrastructure, and configurations and handling compliance based on the regulatory bodies and frameworks.
As a user, we are responsible for maintaining all the IAM resources, enabling security, enforcing password policies, making MFA mandatory, password rotation on a timely basis, auditing credential reports from time to time, analyzing the access pattern of your users, and so on.
For the readers who are preparing for AWS certifications, this article may serve as a starting point to learn about IAM. For a detailed guide try to follow some standard tutorials available on the internet. It can be from AWS itself or some other resources. For my exam prep, I read through the AWS documentation site and the TutsDojo blogs for my exam prep. Attended several mock exams from the website as well which helped me a lot to get AWS certified efficiently.