When I was first getting started in AWS, I had my fair share and experience of dealing with Identity and Access Management ( IAM) before.

Most of the general idea around IAM revolves around users, groups and roles. At the most basic level, it is all about whether a user has access or permissions to do certain things or not.

And for the system to system interactions, it is mostly through certificates or API Key/ Secret etc.

Here are some of my learning of what an IAM is at least in AWS

1. IAM and Identity based policy

Identity is not just user identity, an identity can also mean a resource. In AWS parlance, every single item is a resource. In addition to users having access to various services, every resource in AWS should have access and permission to access other services in AWS.

And all access and permissions are configured via Policies. So if a Lambda needs to access a DynamoDB, Lambda must have policies defined that allow a DynamoDB table to be accessed.

These policies could be mapped to a role and the role could be mapped to a user or group.

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

2. IAM and Resource-based policy

In addition to an identity-based policy, we have a resource-based policy as well. Few AWS services have policies defined at the resource level. Some of them are the S3 bucket, SQS queue etc.

S3 bucket can have its policy defined that can either allow users or other resources to access the S3 bucket. The reason why few resources alone have this is to ensure cross-account access is made easy. For instance, we may have a user or a resource in another AWS account that wants to access an S3 bucket in a different AWS account. Instead of creating a new user just to access the S3 bucket, cross-account access will allow user/resources who are not in this AWS account to access the S3 bucket based on the policy definition done in the S3 bucket policy.

In scenarios where both Identity and Resource policy exists, both policies will be evaluated and if all the criteria mentioned in the policies are met, the access will be provided, else it will be rejected.

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

3.IAM Policy Generator to the rescue

IAM Policy Generator can help to ensure the process of defining policies is made simple. There is a simple user interface that receives few user inputs and suggests the most appropriate policies to be included for the requirement.

http://awspolicygen.s3.amazonaws.com/policygen.html

4. IAM Best Practices

Even though Cloud is generally considered secure, most of the time our lack of understanding of IAM and policies lead to us providing wide access to many resources. This leads to major security incidents as well.

It is important to understand the IAM best practices and ensure the policies are well defined and as much as least restrictive as possible.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

5. IAM Access Analyzer

To ensure the IAM policies are defined correctly, IAM Access Analyzer can be used. This analyzes the resources and associated policies and gives insight/ recommendations based on the best practices.

It would be prudent to enable IAM Access Analyzer and keep monitoring the result of the scans to get a bird’s eye view into the kind of roles, policies that have been configured and tweak them based on our requirement.

https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html

IAM is the fundamental and integral component of every cloud system, be it AWS, GCP or Azure. It is very critical that all of us understand IAM and ensure the best practices are followed so that we do not end up with any major security issue that could cause irreparable damage to the organization or the users.