The curious case of AWS IAM's policies

Do you know what the first thing you will encounter when you start to get to know AWS? Permissions! ⛔

As part of my recently found wisdom that "If I want to learn something, I should teach it", in this article I'll try to write a concise guide about AWS IAM (Identity and Access Management service) and its permissions document AKA policies.

(This piece is based on the official AWS documentation that talks about IAM policies. Consider it as its summary 😉)

Table of contents

• Intro
• Policy Types
  • Identity-based policies
  • Resource-based policies
  • IAM permissions boundaries
  • Service control policies (SCPs)
  • Access control lists (ACLs)
  • Session policies
• JSON policies structure

Intro

I'll ask you a question, what's chaotic and big and don't have permissions? ... The Jungle 🦁🐒🦒
That's what will your AWS be without permissions! Even worse, it could (and probably would) cost you a fortune or make you lose business (or both)!
AWS has its IAM service in place to manage your account's permissions and saves you from all that! How it does that? By using policies. And because I'm a visual learner, I've made this diagram to show you:

Policies are attached to either an Identity or a Resources with permissions as allow or deny and are evaluate when a principle perform a request. They are JSON documents (except for ACLs) and consist of 6 types that we will discuss next.

Policy Types

As I've mentioned, there are 6 types of IAM policies ranked from the most common to the least common as below:

Identity-based policies

Those are the policies that you attach to an AWS identity (user, group or role). They can be managed or inline (one-to-one relation with an identity).

Resource-based policies

When the policy is attached to a resource like S3, it's call a "Resource-based policy". You must explicity state the principles in this case.

IAM permissions boundaries

Think of those as the guard-rails for your permissions. They set the maximum allowed permissions for an IAM identity but they don't give those permissions.

Service control policies (SCPs)

When you use "Organizations", Those can be applied to the organization member accounts or OUs (Organization Units). They can control the maximum set of permissions (like IAM permissions boundaries) for identities AND resources.

Access control lists (ACLs)

The only non-JSON policy type. Similar to Resource-based policies but that give permissions to principals outside of the current account and can't be used for principals inside the same account.

Session policies

When using the AWS CLI or AWS API, you can set advanced policies to assume a role or a federated user by using session policies.

And this is a summary for all the policy types:

JSON policies structure

The structure of a policy is well explained in the docs. It is comprised of the following: (the pic is straight out of AWS Docs)

So for the following Resource-based policy, it just state that the root user of AWS account account-id is authorized to call every S3 API on a bucket called "mybucket" and all the objects within.

And this is a summarization of the different fields:

Finally, I hope that you find this article useful 😊 and see you in upcoming pieces 👋