AWS IAM: an introduction
By the end of this post you will be comfortable with IAM as a service, understand the basic components that make up IAM and be fully, thoroughly and completely exhausted by IAM based puns. Are you excited?? I know IAM!! 😂
AWS IAM — which stands for Identity and Access Management — is one of if not the OG (Original Gangsta) of the AWS services crew. Essentially a bouncer that determines whether you have the necessary permissions to access many of the AWS resources including EC2, S3, Lambda etc. It has authentication and authorisation at the heart of its existence and understanding what IAMs are, how they work and the more nuance use cases will help you navigate the permissions maze of AWS. Let’s dive in!
The Whyyyyyyyy?
AWS as a whole is made up of service after service after service, it is after all an all-encompassing behemoth of a cloud solution made to handle enterprise level operations. And if you’ve been good and completed some sort of security training at some point you’ll quickly realise that more services generally means more entry points and therefore a larger attack vector for people with bad intentions. So how can we handle this?
Well this is exactly where IAM comes in, with IAM you can enable interactivity between resources, but even better than that you can enable the least amount of permissions to get the job done. Why is this a HUGE GINORMOUS deal? If any of your resources are compromised, you have limited the blast radius, rather than compromising your entire AWS account you may just need to kill an EC2 instance. Now that you are convinced IAM more important than any — oh sorry, I meant IAM’s** are more important than air and water — honest mistake — let’s get this party started. MUSIC! LIGHTS! AAAAACTION!!
Note: everything in AWS operates on a deny by default policy, so you gotta explicitly allow something before it’ll work, ahaaaa Unagi!
The smallest component
The smallest and most important component of IAM are JSON based lists of permissions called Policies. Policies are simply a list of Actions that an actor is Allowed to perform on a Resource. Let’s call this actor something more AWS friendly like a Principal — this is a doer of any actions. And for whether or not you are allowing or disallowing an action we shall hereby name this: Effect.
Allowed/ Disallowed > [ Pricipal > Action > Resource ]
So say for example my mom says: “Hamzah please don’t eat anything from the cookie jar”, now I know what you’re thinking, it’ll take more than that to stop this bad boy. But for the sake of education, let’s assume this works and dissect this sentence based on the highlighted words from earlier.
So we have: Policy, Action, Resource, Effect and Principal.
The Principal, the entity doing, or in this particular case NOT doing the action. Hamzah was told NOT to eat anything from the cookie jar, therefore Hamzah is the Principal. Nice and easy, nothing complicated.
The Action, what’s being done here or not done here? The doing word in the sentence has to be eat. Hamzah is told not to eat anything. A crazy ask imo but nonetheless it fulfils the requirements for an action.
Tidbit: There are over 4000 actions available in AWS, that’s not including the cookie one tho, just fyi. Actions in AWS take the form of S3:GetBucketList — this list the resource (S3), then the action that can be performed against it (You can get a list of the buckets in that account). Policies are filled with actions like this that allow, or disallow, the principal to do all sorts of things.
The Resource, what is the prized commodity here? What are you performing the action AGAINST? The cookie jar, exactly! It is important to be specific about your target, can’t get cookies from just anywhere you know!
Effect, did my mom say eat or don’t eat? That’s right! She was like nuh uh don’t you dare go near that cookie jar. So I will say/ cry Disallow.
And finally, the Policy, that’s all of the above put together, the sentence as a whole is a Policy my mom assigned to me, luckily I’m not an AWS resource so cookies galore for me but that’s how simple it really is.
And thhhheeerrreee yoooouuuu have it! IAM a policy master! Well IAM not but you certainly are! Now you can read a policy document and at least understand the higher level overview. Moving on now to bigger and better, ok not better but definitely BIGGER!
This Role was made for you, I just know it!
If IAM is the bouncer then IAM Roles, Users and Groups are the different lists the bouncer checks to see who is allowed in, the A-list crowd. And if your name is on said list, ie you have permission then think of that as a valid Policy — are you cool enough to enter this particular party? OK, so far this analogy is holding up, great! 😊
But I hear you, deep in your mind asking: “well, I see, IAMs are bouncers, but then, what actually are they? Like lists or apps or… IAM confused” 😂 I love this joke. To answer your question, IAM is an AWS service. You don’t add an IAM to an EC2, you add an IAM Role, and in that role you have Policies that you’ve added that detail the permissions you’re giving to the Role and therefore the EC2 instance (Note, if you have a keen eye you’ve probably noticed that in this case the EC2 instance would be the Principal in the Policy), with me so far?
Before we continue, let me explain what Roles, Users and Groups are. These are IAM identities (identities because that’s just a fancy way to identify them — sounds a bit more technical than calling them IAM things), they are very much related to each other as you’ll see. First off, Roles! — they see me rollinn’, they hatiinn’, patrolling they tryna catch me ridin’ dirty.
Roles are a collection of one or more Policies (permissions) that combined together, list out what the principal can or can’t do to other resources.
And essentially that’s what Roles are. Roles can be assigned to multiple resources, for example if you have 30 EC2 instances that need the same permissions you can assign the exact same role to each of them, super helpful! And because they are essentially a bundle of Policies, if you need a new permission you just add a new Policy to the single Role and that new permission is now available to all your 30 EC2 instances. Now, this may lead to you thinking hey, easy peasy, assign the same Role to whatever instance and add permissions galore… No lol nonononono please god no!!
You see, best practise dictates a least privileged approach when it comes to permissions, or really anything that involves access to secure resources. Remember this term: Least Privileges, you’ll hear it anywhere you are doing anything related to security, if I had a nickel for every time I heard this… well…. I would have a lot of nickels, at least 15… or even more! That’s why I said earlier “30 EC2 instances that need the exact same permissions” emphasis on exact same permissions for a reason. You’ll see later on why I make this point but just remember Least Privilege, make it your mantra, print it out, order stickers, say it before you sleep at night, give out nickels to people you say it to, Least Privileges. OK, Roles covered. Next up we have Users.
Users are you and IIIIIIIIIIIIIIIIII… aaaannnndddd also applications. Apps are people too, according to AWS IAM services (here comes the robot rising!, AI consists of two thirds of the letters from IAM… coincidence? Conspiracy? You tell me 🤔 )
Users are similar to Roles in that they are also a bundle of Policies, however, that is where the similarities stop. Users don’t have a many to one relationship like Roles do, they are one to one. Users are also only ever people or apps, they can not be assigned to any other resources within AWS, like you can’t have an S3 User, you CAN have a User that accesses S3 though, very important difference. With the last example, this user accessing S3 would need the right Policy applied and the 2 general ways of access are:
- If they are a person, they can use a separate login link and password provided at the time of User creation to login into their own personal AWS console or,
- If we’re dealing with an app that of course isn’t going to be logging into any GUI console, we are also provided with 2 sets of keys: an Access key and a Secret Access Key
For example let’s say we got a dude, let’s call him Jack Bauer, now Jack is a crazy dude, I don’t really trust Jack all that much, dude is unstable. So Jack wants AWS console access because he wants to look through my S3 buckets on a Saturday afternoon, I told you, Jack plays by his own rules. Now I don’t really wanna say no to a guy like Jack but also I don’t really want to give Jack full access of my AWS account, come to my rescue IAM Users. I create a User, assign an S3 all access READ permission policy. And KABLAAAM, I get a login link for Jack and a password, I don’t have to worry about my AWS account in the wrong hands and Jack gets to spend his crazy Saturday afternoon doing what he loves. Win-Win!
In the same way we create a User for a person, we can do the exact same for an app, except in this case instead of a login page to access the console and a password we use the AWS CLI or SDK and a combination of the Access Key and Secret Access Key to verify who we are. Note, these are together secrets that you should treat as you would a password. Anyone with access to your aptly named Access and Secret Access keys can do all of what you assigned the User when creating it.
Awesome! With that disclaimer out of the way and the smoke of doom and gloom evaporating swiftly we shall cover our final topic of the day: Groups.
Groups are a collection of Users, they make it easier to manage multiple Users and all Users assigned to a certain group inherit the permissions of that group. Simples. If, for example, I was approached every other week by a different deranged member of fictional society that was fixated on having a look at my S3 buckets, all I would need to do is add their User into a Group (appropriately named Crazy Deranged Members of Fictional Society, CDMFS for short) with the S3:Read permissions policy and bippity boppity boom, I’m done. And should I want to remove them, I simply remove them from the Group and there go their permissions!
Well done! You did amazing wow, I honestly didn’t think you would get through this in one piece but I’m so proud of you! I — Oh — Umm… sorry, I didn’t see you there fellow reader, oops excuse me I was just talking to myself about some other stuff completely unrelated… well I am very happy for you too for sticking with me so far, hopefully you learnt some funny annoying puns along the way you are more than free to use and in the middle of all that maybe also picked up some IAM essentials.
So far we have outlined Policies, Roles, Users and Groups on a high level, but this is a great start, you can only go UP from here 😊 well… actually we need to go down I’m using a top-down approach… so YEAH! Super exciting times ahead, IAM sure I have a lot more puns in the mix and a tonne more AWS to learn so let’s go go gooooooooo! Cya!
OK, I promise this is the last one…
Who’s the best authentication and authorisation manager in the whole wide world? IAM ;)
