What are IAM Policies?
From the AWS official docs,
A policy is an object in AWS that, when associated with an entity or resource, defines its permissions. AWS evaluates these policies when a principal, such as a user, makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents.
Let us try to break this down. There are two parts
POLICY SPECIFICATION (defined by us) - We define which IAM principals are allowed to perform which actions on which resources under which conditions.
POLICY ENFORCEMENT (taken care of by AWS) - By assessing the AWS request and the policies defined, AWS validates the access and says whether the request is authorised to perform the intended action.
In a nutshell, Policies provide authorisation to AWS services and resources.
IAM Policy Structure
{
"Statement": [
{
"Effect": "effect",
"Principal": "principal",
"Action": "action",
"Resource": "arn",
"Condition": {
"Key": "Value"
}
}
]
}
Effect: Whether to allow or deny access (Allow / Deny).
Principal: The entity that is allowed or denied access. Since we already connect policies to the IAM entity (user/role), the principal may not be seen frequently. AWS is aware of the principal in this situation. But In the case of another use case where we assign the policy to AWS resources say S3, SQS etc (Resource-based policy) we mention the principal.
Action: The type of access that is allowed or denied.
Resource: Specified resource on which the mentioned action will affect.
Condition: The conditions under which the access defined is valid.
Policy Enforcement
First and foremost the decision evaluation starts with default DENY. Assuming that the principal by default isn't allowed to perform the intended action on the requested resource
Then all the policies are evaluated, this may include policies at the organisational level (Service Control Policy), policies attached to the user/role (Identity-Based policy), policies attached to the resource (Resource-Based Policy), permission boundary and even session level policy.
If there is an explicit DENY, then the policy evaluation stops and access is denied
If not then it checks for an explicit ALLOW. If there is an explicit ALLOW, then the policy evaluation stops and access is granted.
Finally, if there is no explicit ALLOW it by default denies access.
Policy Types
Identity-Based Policies - Attach policies to IAM principals (users, groups, roles)
Resource-Based Policies - Attach inline policies to resources. It can be used to control access to resources. Principals can be in the same account or a different account.
Permission Boundaries - As the name suggests, it can be used to control the maximum permissions that an identity-based policy can grant to the entity (user or role).
Organizations SCPs - Organization SCPs are the higher-level component that defines the maximum permissions for account members of an organization or organizational unit (OU). SCPs do not provide rights; rather, they restrict the permissions that identity-based policies or resource-based policies grant to entities within the account. In a way similar to Permission boundaries.
Session Policies - Session policies limit the permissions that the role or user's identity-based policies grant to the session. we can read more about session-based policy here
How Policies Work Together Within An Account
- As the diagram depicts, first the Service Control Policy should allow (if the principal is a member of the organization to which the Service Control Policy - SCP is attached), and then either the identity-based policy or resource-based policy should allow.
Breaking down step 2,
If there is a permission boundary set, then the intended action should be within the permission boundary.
Similarly, the intended action should also be allowed in the permission policy.
If there is a scope down policy (session policy) it should also allow as well.
Let us try to understand this with some examples,
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
No permission boundary is attached to Bob
Bob has a permission policy that allows SQS: PutMessage
There is no scope down policy (Session Policy)
There is no policy attached to the SQS for Bob.
When,
Bob tries to send a message to SQS
Then, Access is Allowed
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
No permission boundary is attached to Bob
Bob has a permission policy that allows S3: *
There is no scope down policy (Session Policy)
There is a policy attached to the SQS that allows SQS: PutMessage for bob.
When,
Bob tries to send a message to SQS
Then, Access is Allowed. (Though the permission policy attached to Bob doesn't allow access to SQS, the policy attached to the resource allows access to Bob)
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
A permission boundary is attached to Bob that allows only S3:GetObject
Bob has a permission policy that allows SQS: PutMessage
There is no scope down policy (Session Policy)
There is no policy attached to the SQS for Bob.
When,
Bob tries to send a message to SQS
Then, Access is Denied. (Though Bob has access to SQS the permission boundary restricts Bob only to getting objects from S3)
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows S3: GetObject
No permission boundary is attached to Bob.
Bob has a permission policy that allows SQS: PutMessage
There is no scope down policy (Session Policy)
There is no policy attached to the SQS for Bob.
When,
Bob tries to send a message to SQS
Then, Access is Denied. (Though Bob has access to SQS the SCP at the org level limits access to principals only to getting objects from S3)
How Policies Work Together Across Accounts.
When you closely look at the diagram, this is similar to how policies work together within an account but the only difference is both Identity-based Policy and Resource-based policy should allow access.
Everything boils down to trust, and access within an account is trusted and the cross-account access is not trusted unless explicitly said.
Let us try to understand the same with some examples,
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
No permission boundary is attached to Bob
Bob has a permission policy that allows SQS: PutMessage
There is no policy attached to the SQS in OrgProduction for Bob from OrgSandbox.
When,
Bob tries to send a message to SQS in OrgProduction
Then, Access is Denied (Though Bob has access to SQS, OrgProduction doesn't trust OrgSanbox unless explicitly said)
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
No permission boundary is attached to Bob
Bob has a permission policy that allows only S3: GetObject
There is a policy attached to the SQS in OrgProduction for Bob from OrgSandbox.
When,
Bob tries to send a message to SQS in OrgProduction
Then, Access is Denied (Though SQS allows access to Bob, Bob by default doesn't have access to SQS and OrgProduction doesn't trust OrgSanbox unless explicitly said)
Given,
Bob is part of the organisation OrgSandbox, to which SCP is attached that only allows SQS: PutMessage
No permission boundary is attached to Bob
Bob has a permission policy that allows SQS: PutMessage
There is a policy attached to the SQS in OrgProduction for Bob from OrgSandbox.
When,
Bob tries to send a message to SQS in OrgProduction
Then, Access is Allowed
And finally, we have come to the end of our journey in demystifying IAM Permission and policies. I hope this would have helped and been a good refresher/eye-opener for you.
I welcome you to drop a comment if you have any questions or suggestions.
Also, do check out this wonderful blog AWS IAM Policies: Best Practices And How to Create an IAM Policy Thank you!!!