Using Permission Boundaries to Delegate Permissions in AWS IAM

Andrew is the Cloud Architect for the XYZ company and has full administrative permissions in the company’s AWS tenant. XYZ has recently hired a new IAM administrator for the security team, named John. Andrew receives a ticket to setup an IAM account for John and provide the appropriate level of access. John needs to be able to manage groups, roles, IAM users and permissions within the AWS account. Andrew assigns the ‘IAMFullAccess’ permissions to John’s account.

Andrew calls John and provides him with his credentials and closes the ticket. Time to make a coffee. Right?

Not so fast. Andrew has provided access to what John needs, but in doing so, has created risk. John could add additional permissions to his account or even create a brand new account and assign it ‘AdministratorAccess’ permissions.

We can mitigate the risk of privilege escalation and delegate permissions by using permission boundaries.

Boundary policies are JSON documents that create a sort of “fence” around IAM permission policies. These policies can either be policies assigned to an IAM user or a role and limit what permissions an identity can receive. These policies are created as managed policies so they can be used with other users in the future. Remember, access is implicitly denied unless there is an allow.

There are two objectives that Andrew needs to meet to properly secure John’s account.

• John needs to be able to administrate IAM but should not be allowed to modify his own account
• John should not be able to create new users with higher levels of permissions than what he has (No AdministrativeAccess for example)

John already has the ‘IAMFullAccess’ identity policy applied to his account. The ‘IAMFullAccess’ policy was assigned earlier to provide John access to what he needs to do.

We can then create a boundary policy that will restrict John to exactly what we want to allow him to do. Let’s look at the first part of this boundary policy:

This part of the policy establishes a permission boundary that allows a user to perform specific actions within IAM, so long as that new user has the ‘IAMuserboundary’ permission attached to it. We’ll explore that boundary in a moment.

The next part of this policy permits John to perform defined actions, so long as he does not perform them on himself. This will allow John to do his job without the risk of privilege escalation.

The final piece of this administrative boundary policy prohibits John from modifying or deleting the ‘iamuserboundary’ and ‘iamadminboundary’ policies.

With this policy in place, we can successfully limit what John can do with his IAM administrative permissions.

Finally, we need to create the ‘iamuserboundary’ policy. This policy limits any users created by John to only have access to services defined in the policy. The remaining permissions in the policy allows the user some limited functionality in the console. Namely, to change their own password and obtain their access keys. This policy will need to be applied to any user that John creates. This is enforced in the administrative boundary policy at the beginning of this article.

John is now set up to properly provision IAM users to have access to predefined services without the risk of privilege escalation. Let’s rehash on what has been done.

• John’s IAM account was given ‘IAMFullAccess’ permissions.
• We created and assigned an administrative boundary policy that establishes what permissions John can perform in IAM and requires that all new accounts have the ‘iamuserboundary’ policy attached. This same policy prohibits John from removing the administrative boundary.
• The ‘iamuserboundary’ permission ensures that John is never able to provide more access to AWS than what his supervisor has approved. In this case: S3, Cloudfront, VPC, EC2 and Cloudwatch. If John ever is required to be able to provide access to additional services, the user boundary policy can be modified.

Looking to learn more about your capabilities in AWS and how they can improve your IAM strategy? Get in touch below to speak to an ivision cloud expert.