Restricting Policies

When do we need a permission boundary?

Permission boundaries are mostly useful when we want to limit the permissions of an IAM entity created by using an IAM user account. Consider a scenario where we’ve created an IAM user account with permission to create other IAM users or IAM roles and provided the credentials to our admin so they can manage the account. There is a sensitive document stored in one of the S3 buckets, and we don’t want anyone, including the admin, to access that document. So, we’ve not included the permissions required to access that document in the policy attached with the IAM user for the admin. We would think that our document is secure as the admin doesn’t have permission to access it, but in reality, it is not secure. The admin can create another IAM user account with permission to access that document and then use that account to access it.

What we need here is a tool that we can use to set an upper bound on the permissions the admin can provide to other IAM entities. This is where the permission boundary comes in. We can attach a permission boundary with the admin that denies access to the S3 bucket, and in that same permission boundary, we can add a condition that the admin should not be able to create a role or a user unless they add the same permission boundary with them. This closes all avenues of access to the S3 bucket, giving us the protection that we require.

Similarly, we can enforce other policy statements as per our needs.

Session policy

Similar to permission boundaries, a session policy is a restricting policy. Its application is however different from that of permission boundary. Session policies are used to set an upper bound on the permissions of a session which is created when a role is assumed. It can only be attached when a role is assumed programatically. The session policy is sent as an argument along with the request to assume the role. It can be both an inline policy or a managed policy. When a session policy is attached with a session, the effective permissions are the ones allowed by both the session policy and the IAM policy attached with the IAM role using which the session has been assumed.

When do we need a session policy?

An IAM role can be used to create multiple sessions at once. By default, the permissions of each session are the ones allowed by the IAM policy attached with the role. Consider a scenario where we've created a role to provide temporary access to external individuals in different roles. We have an admin access policy attached with the role that allows the assuming entities to perform all the actions within that account. What we want next is a tool to limit the permissions of each session based on the role of the individuals assuming the role. This is where session policy comes in. We can attach a session policy with each session, based on the role of the individual allowing them to perform only the actions that should be allowed to that entity.

So if we're creating a session for an entity to manage DynamoDB operations, we'll attach a session policy that'll restrict that entity from doing anything out of the scope of their role.

Effective policy

Now let's look at what would be the effective policy in case an entity has both the permission boundary policy and session policy attached with it. The diagram below depicts the effective permissions for such a scenario:

For denials, an explicit deny in any of these policies overrides the allow. The diagram below depicts the effective permissions for such a scenario:

To summarize, both permission boundary and session policies are very useful when defining and enforcing access controls within an AWS environment, especially when there is a need to manage and limit permissions for IAM entities in a granular and controlled manner.