In this article, I would be writing about what the AWS IAM really is. The IAM stands for Identity and access management and consist of two parts:
1) Identity Management: this is the process by which a user requires authenticated credentials to access the AWS account, in summary, you can call it the AWS account login details. It usually comprises of username alongside password, multifactor authentication (MFA), or federated access to the AWS account
2) Acces Management: this is the authentication that allows a user that has been authenticated and logged into the AWS account to have access to the AWS resources like S3 bucket, EC2 instance, RDS, etc.
The components of Identity and Access Management are:
1) Users: this consists of different users in your organization who would access your AWS service
2) Groups: they comprise multiple users who are defined by their similar job specifications or roles.
3) Roles: they are objects which ensures the AWS resource has access to specific temporary permissions
4) Policy: they are a set of control instructions that determine if a user, group, or roles are allowed or not allowed to use a resource and they are usually in a JSON format.
It is to be duly noted that it is the best practice to assign permissions to groups other than roles as this would make work easier and reduce the level of administrative complexity. So the steps should be as below:
1) Create a group
2) Attach permission to the group
3) Create a new user
4) Assign the user to the group (the user automatically inherits the permissions from the group)
5) Set up a new service role
6) Apply the created service role to the AWS resource so the permissions can be utilized by the resource
I would also like to discuss and expatiate further on the Policy part of the IAM. They are two types of policies, and they are:
1) Managed policies: it can be subdivided into two parts:
a) AWS Policy: they are policies that have been predefined by AWS
b) Customer Policies: they are policies that are created by the user. They can be done by editing an already made AWS policy, using the policy generator, or by creating a customized policy in JSON format
2) Inline Policy: they are policies that can only be added to a specific user, group, or role.
It is to be noted that, the difference between the managed policies and the inline policies is that, the managed policies can be attached to multiple users, groups, or roles but the Inline policies can only be attached to a specific user, group, or roles.
I have made mention of MFA above, but what really is MFA. It is an acronym that stands for Multi-Factor Authentication and is usually required as a security measure for some specific users who have access to large AWS resources.
Lastly, before I bring this article to a conclusion, I would like to discuss what the Identity Federation is. Identity Federation allows users to access AWS resources without having IAM access. In order to use this functionality a trusted relationship is established between the identity provider (which performs the authentication of the user) and the AWS account. Some notable identity providers are Microsoft Active Directory, Open ID, etc. Identity Federation has the advantage that it reduces the amount of IAM access that is required to be created.