I.A.M Stands for Identity Access Management.

Basically, anyone who wants to use AWS, has to have some sort of access.

In terms of business need, This is solving a problem that AWS (and other cloud services create). When everybody can log into the console, not everybody can have access to the same things. Where in the past if you have an IP address, username and password, you’d be able to log in, now AWS has to control who can do what on there otherwise your company would be paying a lot of MONEY!!!!!

Now imagine you your boss comes to you and tells you, Ramzi, we need to move our services from on premises to AWS. Can you take a look and let let me know what is needed.

So Ramzi goes onto AWS and creates a new account.

Congrats, you just created a Root User account. And you have access to everything on there.

You also signed in using Single Sign On which as most people know now, that’s no good. And the first thing thing that should be done is enable multifactor authentication.

Now the first question that popped in my head is, what if Ramzi leaves the organization. What happens to the root account?

Well, it turns out you can transfer it. so that’s good.

But now, let’s say you did your research. Yes, we can move to the cloud. All these services we are running can now go!

But same as when the datacenter was running on premises, not everybody should have access to everything. As a matter of fact, new users have 0 permissions and you need to provide some.

Administrators would have more access than HR for example. HR’s access would be limited to using applications on specific systems, but never to launch a EC2 (or VM) for example, or more importantly, shut one down.

You can give permissions to a Group, a User, or a role.

Best practice is to give permissions to groups.

So instead of giving each HR person, or as AWS calls them, Users, a policy, or You can have an HR Group and add a policy to them. AWS provides the options for Group Policies so you might not need to create new ones.

So you can say something like all HR get the following permissions. Developers get the following.

All these permissions and policies are found in a JSON file which say what each group or user can do on the AWS account.

Side note, I could not think why an HR person would have access AWS, so I asked chat GPT, and it said that in case a certain HR person needs to manage an HR specific application, or needs to do some analytics.

When I ask ChatGPT for links where this info can be found, it sends me to the IAM documentation. So, if you know anyone in HR who can explain it to me, I’d love to hear it.

Finally, there is also the concept of a role. What is discussed in both Cloud Guru and Stephane’s Mareek’s course is that this relates to the services that are being used on AWS.

For example, you have an EC2 instance being used as a web app, and a database that is used by this web app, then that EC2 instance needs permission to access the database.

Without that, these 2 services might not be able to connect together. There is a bit more complications with security groups and stuff, but that is the basics of a Role in IAM.

If you want more information, here’s the link: https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

Some rules that we might need to adhere to:

1- The Principle of Least Privilege

Don’t give people more privilege than they need to do their job. So when in doubt, don’t give out…privileges.

2- Users inherit permissions from the groups, but not vice versa.

3- Even if you have root account, don’t use it for your day to day.

Now if you’re in an organization say, amazon, and each user needs to use their amazon email address and password so you don’t have to remember multiple ones, you can use IAM Federation which uses the SAML standard.

So I had to briefly look up SAML and it stands for Security Assertion Markup Language and is used for exchanging authentication and authorized Data between parties, in this case you’re companies Active Directory and AWS!