Automate Permission Boundary Attachment to IAM roles and Users

When we are managing multiple AWS Accounts in an Organization and each accounts will have their own requirement but as a centralized admin, we should be having a certain governance and compliance framework. IAM is a widely used AWS service and IAM roles/users are common used entity in AWS. As a centralized Admin, when we provide access to create IAM roles, cloud consumers in the landing zone accounts would create Users and Roles and attach Administrative policy and bypass the governance framework. In this blog, I will be briefing on restricting this scenario using IAM permission boundary and also deploying this setup through automation.

AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

Architecture Design

It's pretty straight forward, when an IAM role is created, above workflow will automatically attach permission boundary to the created IAM role. This is a cost-effective automation and cost included in this setup is very minimal

AWS services used for this Automation

Event Bridge: AWS Event Bridge is very widely used service when it comes to Automating a scheduled or event trigger. We would be configuring Event Bridge rule to capture CreateRole Event. When IAM CreateRole Event is made, EventBridge will trigger the AWS Lambda

{
  "source": ["aws.iam"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["iam.amazonaws.com"],
    "eventName": ["CreateRole", "CreateUser"]
  }
}

AWS Lambda: Lambda function is to call an API to put permission boundary to the created IAM role

CloudWatch Alarm: As a best practice, always have a detective mechanism for the lambda function failure, since we customize the code and will have loops, condition, API etc in the code and there would be a scenario where lambda function would fail to different reason, so we are going to have an Alarm configured to capture the failure and send to SNS topic

SNS Topic: When a lambda function throws an error, CloudWatch Alarm triggers SNS topic and from the topic, we can publish the error message to various notification channel

Permissions Boundary (IAM Policy): Based on your requirement, you can write a managed policy to restrict the required permissions

Note : IAM is global and all IAM related events will be captured in us-east-1, so deploy this automation setup in N. Virginia region

SCP or Permission Boundary?

In Layman terms, use the service control policies to protect platform resources, otherwise keep it on permissions boundaries. There would be a situation where that’s just not possible for a variety of reasons, mainly on SCP document size limits. In those cases we have to make use of permission boundaries.

Conclusion

In this blog post, I have shown you on how to automate permission boundary attaching to an IAM role or User. Along with that we looked on how Service Control Policy and Permission Boundary can be used effectively. Hope this blog helped you in your similar use case.

Thank you for reading!