IAM or identity and access management is an AWS managed service that allows you to manage who can access your cloud resources. This thus plays a vital role in maintaining the security of your infrastructure.
Although you need not know it’s working to work with it, but knowing the internals is always a good practice, especially when it comes to sensitive issues like security.
So, how exactly does IAM work?
Let’s leave the fussy technical way and go around intuitively to understand the working better.
What do you do when you want someone to do something for you?
You ask them! Same is the case with IAM.
You first have to ask AWS to do something for you. This step is called request.
That was nothing new and you probably knew it. But how exactly do you tell IAM what you want or in technical words, what is the structure of a request.
If you have sent any request to AWS, you definitely want to perform some action on one or more data object using some of the AWS services.
That’s all there is to a request.
It consists of actions or operations, resources or the service that you wish to use and resource data or the data object on which you want to perform the action.
But where did the security part go? Wasn’t IAM responsible for it? How does it ensure it?
To make sure no security compromises take place, IAM makes sure that a request in addition to the above data has principal or the user, group or service sending the request.
So this forms a total of four components,
- Resource Data
And now the final thing, some metadata about you, or rather your environment data like the IP address, SSL, etc
Once a request is made, it is gathered into a request context.
That’s none of our business. AWS official document states nothing about it.
Now, coming to the next step.
You’ve told AWS you want to perform a certain action and who you are, but security is all about suspicions
AWS will now check if you are who you say you are. That’s where principal comes into play. It will see your password, access key, secret access, all depending upon how you interact, via console, CLI or command line.
Using this information, it will validate if you are a genuine user or not.
If you are not a user, you are kicked out else the next step follows.
So let’s assume you’ve made so far and you are authenticated. But IAM is responsible for access management too.
The next question that AWS asks is that “okay, you are a genuine user (or group or role), but are you even allowed to perform such an action?”
At this point it will search through all of your permissions to see whether are are allowed to perform the operation or not.
This is the best part about IAM.
It has something called explicit allow and explicit deny.
Let’s cover them one by one.
By default everything in AWS is a big NO.
If you are not assigned any permissions, you don’t have any. Simple.
So, when you make a request, IAM goes through a list of all your permissions. If you have an allow on all of the actions, you are given a green flag, but, if any one permission is not given, none of the actions specified in the request will take place. This is called explicit deny.
And when you are given a permission, and you override the default deny, it’s explicit allow.
Enough of technical terms. Now let’s get back to our journey of IAM
Actions Or Operations
Once it is confirmed that you are who you say you are and you even have permission to do what you intend to do, guess what, you are allowed to perform the actions.
And finally the requisite action is performed on the AWS resource. This resource could be an EC2 instance, S3 bucket, etc.
But remember if you provide a wrong resource, like an S3 bucket’s arn while trying to deploy an EC2 instance, you know what will happen.
Your request will be denied.
Now to summarize it all, there are in total 5 steps,
- Request: It is asking what you want
- Authentication: Telling who you are
- Authorization: Checking if you have valid permissions
- Actions or operations: Doing what you want
- Resource: Telling where to perform the action