AWS IAM role

Hello and welcome to my blog where I share my technical knowledge with the rest of the world. Today I will be writing on AWS IAM(identity and access management roles).
In today's article, I will write on;

1. What is an AWS IAM role?
2. How AWS IAM roles work
3. Architecture of AWS IAM role

What is an AWS IAM role?

It is a type of identity in an AWS account. It is used by other identities, services or applications either inside an AWS account or outside an AWS account to gain access to resources inside an AWS account. For example, assuming you're designing a system where users are more than 5,000, it's prudent to issue a role that the users could assume and be able to gain access to the services stated in the permission policy statement of the role.

Another example is, assuming you're a cloud engineer who joined a company that has 3 AWS accounts; one for staging, QA and production. The company has about 50 engineers each with their IAM user accounts and these engineers all need to access AWS accounts. Technically, managing the accounts of these users would be hectic. The best way to grant them access to these accounts is to create a role with permissions that will enable them to assume roles to the numerous AWS accounts of the organization with the same IAM user account without adding them to the other accounts or creating another identity user in the other accounts.

Roles are identities that are used by other identities, services and applications in the short term. These identities, services or applications assume the role for a short term, they become the role, they gain access to the permissions inside the role, borrow and use the permissions that role has and then they stop being that role.

AWS IAM roles have 2 types of policies which could be attached; trust policy and permissions policy. The trust policy controls which identities(IAM users, services and applications) can assume that role. For example, if you're working in a company that has three AWS accounts and you need to access let's say staging account, the AWS administrator would have to add your IAM user to the trust policy before you could assume a role into the staging account. Permission policy specifies which services and identity can access after assuming the role. For example, let's say you're an AWS administrator and you need to grant access to an employee who is a cloud engineer to access the staging account of your company's infrastructure. You will first create a role, then add the employee's IAM user in the trust policy. You will then specify in the permissions policy what services that employee could access after assuming the role and accessing the staging account. Say, you want the employee to access only an S3 bucket, you will specify it in the permissions policy.

When a role gets assumed by an identity that has been designated in the trust policy, AWS generates temporary security credentials called STS(secure token service). STS is like access keys but used in the short term and are timed. They work for a certain period and expire and once they expire, new STS needs to be generated for the identity before the identity can assume the role and access whatever services or resources designated in the permissions policy of the role. Every time the STS is used, it checks against the permission policy.