The other side of AWS IAM Permissions
IAM Policies
This article will not be an in-depth look at IAM Policies, but it’s a good idea to go over the general basics.
An IAM Policy is in the form of a JSON Object with the most important part being the statements.
Each Policy Statement defines a set of actions, whether the action should be explicitly Allowed or Denied, and under which conditions the statement should apply.
The conditions come in 3 types:
- Principle - Who is performing the action
- Resource - The resource the action is being performed on
- Condition - More complex logic that looks at the context of the api call and the attributes of both the principle and the resource
An IAM Policy will not typically have a Principle condition as that is trivial.
The IAM Policy is attached to a User/Role and that User/Role will be the principle the statement is matched against.
Whenever there is an action being attempted, that action is checked against all the statements of all the policies (or Boundary) attached to the User/Role. The action is allowed only if there is an explicit ALLOW and no explicit DENY statement for that action.
Order of precedence:
- Explicit DENY
- Explicit ALLOW
- Implicit DENY
The permissions granted by both the attached IAM Policies and Permission Boundary attached to a User/Role define it’s Effective Permissions.
It defines what actions are allowed to be taken under certain conditions FROM THE USER’S PERSPECTIVE.
(Note that my use of ‘perspective’ is just an anthropomorphism)
Resource Policies
The distinction that IAM Polices work FROM THE USER’S PERSPECTIVE is very important because there is actually another side to any action: the resource’s perspective.
Resource Policies define what can be done to a resource FROM THE RESOURCE’S PERSPECTIVE.
you’ve likely already used Resource Policies before, it’s just that AWS does not use that term. They prefer to call it something different based on the resource type it is applied to, but as a more general term they all fit into the same general framework.
Examples of common resource policies include:
- Bucket Policies
- SNS Topic Policies
- IAM Assume Role Policies
- Lambda resource-based policies
All these resources have the same syntax as IAM Polices and work in a similar way.
These Resource Policies may or may not require defining the Resource portion of the Statement given the resource in question is the one the Resource Policy is attached to.
They are created and attached in different ways but fill the same purpose in the IAM framework.
Being a bit more formal: there is an Principle who is attempting to perform an action, a Resource that the Principle is performing the action against.
For an action is work both both the Principle must be able to do the action and the Resource must allow that action to be done to it.
The IAM Policy (and Boundary) define what the Principle can do to a resource and the Resource Policy defines what the Principle can do to it.
If a Person A (Principle) wants to punch Person B (Resource), Person A must not be in a Straitjacket and Person B must not duck.
Here is a diagram that brings the whole set of Policies together.
- IAM Policy - What permissions are granted to the user ro role
- Permission Boundary - What is the upper-limit to a user’s or role’s permissions, assigned directly to the user or role
- SCP - What is the upper-limit to a user’s or role’s permissions, assigned account-wide
- Effective Permissions - What actions can the user do FROM THE USER’S PERSPECTIVE
- Resource Policy - What actions can be done to a resource FROM THE RESOURCE’S PERSPECTIVE
- True Permissions - Set of actions that a specific user can actually do to a specific resource
