AWS IAM: Identity vs Resource Policy

Policies come in all sorts of different shapes and sizes, kinda like chocolate I guess 🤔 Toblerone, Dairy milk, oh oh oh Ferrero Rocher, and then you have those Lindt ones and the Truffles that literally just melt in your mouth omg yessss… wait, what were we talking about? Oh yeah, Policies! Yes haha oops

There are 6 key types of chocolates — I mean policies** and today we will explore the 2 most commonly found ones: Identity and Resource based Policies. We don’t care about the others… well just for today we don’t care… I mean they’re kinda actually super important but for today, We. Don’t. Care. 👏

Identity based policies vs Resource based policies 💪 . OK they’re not an either or tbh, they have different use cases but that doesn’t build up anywhere near as much drama and suspense as a match up!

Now from what we’ve covered so far on this you may recall that identity based policies don’t have a Principal attribute. That’s because they assume that the Resource the IAM Role is attached to IS the Principal, the actor. Makes sense, right? That they’re called an IDENTITY policy, you are therefore specifying the identity of the Resource. What the Resource can do.

Note: A key point to remember is that policies attached to a resource define its permissions. Whether that’s specifying what they can access (Identity based) or what can access them (Resource based). Once you understand that, policies become super simple. Great!

Here we have this super amazingly well drawn piece of art by yours truly that shows where the Principal would come from in an Identity based policy.

How an Identity based policy works out its Principal

There are 2 types of Identity based policies:

• Managed policies, and
• Inline policies

Managed Policies

Managed Policies are the grown ups, completely independent, they got their own job, they’re living their best life and they don’t need mom or dad cramping their style. They can further be categorised into:

• AWS managed policies and,
• Customer managed policies

Managed policies can be applied to any Identity (Roles, User or Group) and however many different Identities as possible, but what’s IN the policies and whether you can change that is where the distinction lies.

fancy box for AWS managed policy

For AWS managed policies, the internals and actual specifics of the policy are defined by AWS and you can’t change that, you look at the options available and choose what best fits your situation. You’re basically at the supermarket and what you see is what you get. I like to call these the off the rack policies. You’ll see why in a little bit. AWS managed policies are denoted in the console with the fancy AWS yellow box icon (shown above).

In Customer managed policies YOU pick exactly what goes into your policy document, either via the console where you can make use of the Policy generator provided by AWS and tick boxes granting specific Actions and that generates your JSON, oooorrrrr, if you’re high techie techie go crazy and build your own Policy JSON document from scratch!

Managed policies are unique because they are reusable and centrally managed. Where Inline policies, that we will explore soon, are very specific, managed policies have ARNs that allow them to be identifiable as IAM entities and therefore referenced in many other identities (Roles, Users and Groups).

And since the one instance of the policy is referenced in many places it is therefore centrally managed. Changing this policy (remember you can only change the customer managed policy) will affect the permissions of all the identities that referenced and used this policy. A domino effect… or a very accurate game of Chinese whispers 🤔

A fun way of distinguishing between the two is thinking about the the difference between:

1. a shirt you found in a shop on the rack (AWS managed), that has set sizes (small, medium — lol like the name of this platform — and large) and materials, and
2. a silky, made to fit, custom tailored shirt that hugs your body, brings out those browns in your eyes and makes you feel like you were made to wear this shirt (Customer managed — also I think I went too far with that tailored shirt comparison…)

Inline Policies

Finally we have inline policies, these are hella specific, like maybe there are a few peeps out there with the same body shape as you, so you can share customer managed policies, but inline? Wow it really doesn’t get more personal than this. Inline policies are also ones you create and manage yourself, but further to that they are applied directly to the IAM identity (User, Role or Group). They are 1:1, you apply them to a specific identity and that’s it (unless you copy and paste the whole thing to another Identity which is literally the only way to make a copy — as you can tell, they weren’t made to be reproducible).

What to use and when?

Generally, if you’re new to AWS, it’s recommended you use AWS managed policies, or if you want a ready made policy for a specific job function, ie you assign the PowerUserAccess policy to users that will have almost full access to all services in AWS but limited access to IAM and Organisations (Organisations is a very important topic we will cover soon), this is a key use case for managed policies. AWS are always releasing new services and APIs and if you are using these AWS managed policies for assigning permissions to your main job functions then they will be updated and kept relevant by AWS, no worries on your part. But let’s say you’re not that easy, you want a custom experience, you wanna be made to feel special, well here we have Customer Managed Policies.

Managed and inline policy summary

Customer managed policies are way more granular and are best used in more specific use cases, say you need to access an S3 buckets contents from an EC2 and that was all, no sense giving your EC2 instance full S3 admin access (please don’t do this lol).

Note: IAM policy versioning for customer managed policies. If you change a customer managed policy (think custom tailored shirt), AWS under the hood won’t override your policy but secretly create a new one. Sneaky sneaky. This is so that you can easily revert back to an older version if you maybe made a mistake or were trying something out that horribly failed — you can revert back up to 5 versions! That’s a lot… AWS must know me very well 🤦🏻‍♂️

Inline policies are in most cases not recommended by AWS. But when you do use them it’ll likely be for single use permissions that you don’t want to risk mistakenly assigning anywhere else. They help you maintain a 1:1 relationship between permissions and principal and most importantly when you discard the IAM Identity the permissions are discarded along with it.

Resource based policies

Remember how inline policies are hella specific policies that live and die along with their IAM Identity? (We ride together, we die together, bad policies for life 👊 ) Well Resource based policies are basically inline policies but applied to an AWS resource instead (like S3 or KMS or SQS or SNS etc).

S3 Bucket Policy example

This is because they are specific and custom to that resource. They are most commonly found in S3 in the form of a Bucket Policy.

This S3 Bucket Policy example looks super familiar, right? Isn’t this just an Identity policy? I see Effect… I see PARC. What’s new?

The P is new. Principal is a field we’ve spoken about A LOT. Like A LOT A LOT. But here we see it in action… no pun intended 😋 Exciting things are HAPPENING!!!! 🎉

Now we’re already pros, we know what’s happening. But because I like to work through this bare with me. We have:

• a single statement
• It is DENY-ing something Okok.
• The Principle has a multi character wildcard (*) so it’s saying anything and anyone can access this bucket, ok I don’t like that but fair enough
• And whomever is accessing this bucket can perform the action s3:* which means anything S3 related, wow, that’s a lot of access to give to anyone
• And the Resource. Well this is the interesting bit, we know what the resource is right? Of course it’s the S3 bucket. I can’t define permissions here for anything else 🤷‍♂️ so why the specification? Well, the answer to this lies within our policy itself. We are granting permission to use any S3 ACTION on the bucket. BUT, some actions are applied to the root of the bucket, and others to the contents of the bucket. Therefore we need a way of specifying both targets. Where we have two values in the Resources section, one with a backslash + wildcard ( /* ) and one without. The one without denotes the root of the bucket, and actions such as s3:ListBucket that lists the contents of the bucket needs access to the root of the bucket. Whereas actions such as s3:GetObject that retrieves a specific object from within the bucket needs access to the file paths within the bucket, file paths represented by the multi character wildcard (*)
• The condition is where my anxiety is somewhat put to rest. Here the policy says if the person or thing trying to access this bucket and its contents is NOT from this IP address then DENY them. A double negative. Some times policy documents have double or triple negatives I have to sit and really think about so if you’re the same don’t worry, it gets better with time… well I mean it can’t get worse can it? 🤷‍♂️

Where in Identity based policies you state what they can access, Resource based policies say what can access them. This is why the Principal attribute is key here, it exactly defines the entity that can access the resource. The elitist of the elite, like one of those invitation only super exclusive clubs, don’t call us, we’ll call you 👌

Conclusion

In conclusion, the end, thank you 🙏

Policy types are use case specific, here we have covered just 2 but with what you’ve learnt here you will be able to decide which one to pick and when. And eventually, we will cover the other policies and then finally we will cover policy evaluation logic (This will help us figure out how all the different policies interact with each other and how AWS evaluates them) which is hands down the most exciting aspect of IAM and I am honestly so EXCITED to write about this!!! oh and also some really cool stuff regarding conditions which I picked up a few days ago and also policy variables and omg I honestly can’t wait!!!! haha 😆

Until next time, stay safe, stay fresh and keep being AWSome 😏