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
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:
| Policy Type | Format | Applied To | Gives permissions? | Can be attached to/affect the Root user |
|---|---|---|---|---|
| Identity-based policies | JSON | IAM identities | Yes | No |
| Resource-based policies | JSON | Resources | Yes | Yes |
| IAM permissions boundaries | JSON | IAM identities only | No | No |
| Service control policies (SCPs) | JSON | IAM Identities/Resource | No | Yes (for member accounts) |
| Access control lists (ACLs) | non-JSON | Resources | Yes | Yes (of other accounts) |
| Session policies | JSON | IAM Identities | Yes | No (probably!) |
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:
| Field | Short Description | Required | Type | Values | Notes |
|---|---|---|---|---|---|
| Version | Specify the version of the policy language | Yes (probably!) | Text | "2008-10-17" / "2012-10-17" | |
| Statement | Use this main policy element as a container for the following elements | Yes | JSON Object | Varies | |
| Sid | Include an optional statement ID | No | Any | Varies | |
| Effect | Indicates whether the policy allows or denies access | Yes | Text | "Allow" / "Deny" | |
| Principal | The principal which the statement applies to | Required in only some circumstances | List | Varies | If you create a resource-based policy, you must indicate the account, user, role, or federated user as the principle. |
| Action | Include a list of actions that the policy allows or denies | Yes | List | Varies | Notes |
| Resource | The resource to which the action applies | Required in only some circumstances | List | Varies | If you create an IAM permissions policy, you must specify a list of resources to which the actions apply |
| Condition | Specify the circumstances under which the policy grants permission | No | Special Syntax | Varies |
Finally, I hope that you find this article useful 😊 and see you in upcoming pieces 👋
Top comments (0)