Role Shopping: Embrace Your Tags

Role Shopping: Embrace Your Tags

In ScaleSec’s Modernizing Security: AWS Series, we discussed Rightsizing Your IAM Policies and the helpful tools and best practices that are available to you. But what do you do when IAM permissions have already creeped? You want to rightsize your IAM policies, and embrace least privilege, but you might be starting from a position of permission sharing within your AWS account. What do you do when those privileges have production dependencies on multiple applications?

Least privilege is achieved when the permissions granted to an entity are limited to the minimum set of permissions required to perform its day-to-day activities. If this entity were to be compromised, least privilege will reduce the attack surface as much as possible in the case of unauthorized access. Operationally, it also means that the minimum possible resources and data will be impacted if something goes wrong. Achieving least privilege is a continuous journey, but the first step is always to remove unused permissions which are clearly not needed. Once unused permissions have been eliminated, consider permissions shared with more than one entity; multiple applications or users.

For more actionable guidance on least privilege in IAM, check out Rightsizing Your IAM Policies.

Role Shopping

Role shopping is when an application team, or single engineer, reuses existing roles by going shopping along the available Roles listed in an AWS Account’s IAM Resources. It occurs when a developer finds and uses a role that already exists, instead of creating one that suits the application’s need; regardless of what that role might be intended for, or who is responsible for its management. Role shopping creates serious security and operational risk for the environment, compounded by every new application which shops this role. Role shopping for this article is addressing roles used by “non-human” users. Any tooling, application, automation or AWS service which needs to use a role for access is in scope.

Security Risks of a Role Shopped Role

Broad permissions make a role a good candidate for shopping. Use of permissions like ‘Resource’ : ‘*’, and wide covering services like allowing ‘s3:*’ in IAM Policies makes easy use for multiple applications. If an IAM policy granting permissions has the specific ARNs¹ of resources inside the policy, it would not make for a good role shopping candidate because the permissions would be locked down. A shopper supporting another application would not be able to use the IAM role to access resources outside of what’s intended for that application.

Any application using broad ‘Resource’ : ‘*’ (wildcard) resource permissions will have access to all of the resources of that type within the AWS Account. If that application is misused or compromised, an attacker will likewise gain access to all of those resources. If multiple applications are using the same role, this creates a larger attack surface and increases the likelihood that someone with malicious intent will gain unauthorized access to your resources and data.

At a minimum, every application should have its own role. Ideally, an application should use unique roles for different tasks and activities. Removing shared permissions ensures that an application will not have access to resources or data that is not needed by that application. If these credentials were wrongfully obtained, no other applications should be impacted. Avoid unintended farther reaching access into other applications, data and beyond in your cloud environment.

The true custodian or owner of the role is typically only responsible for the originating application’s access and uptime. Other applications which choose to shop this role are at the mercy of the changes the role owner makes. There could be cascading or unforeseen consequences for the other “shoppers” of this role if permissions were changed or removed. The role owner would likely only know about its own application usage unless they are closely watching AWS CloudTrail logs. Depending on the number of applications which have shopped this role, it can be very difficult to identify which application represents which activity in AWS CloudTrail.

Decoupling IAM Role usage in order to safely rightsize IAM policies can be a complicated exercise. When multiple applications with different functions and resources use the same IAM Role in the same AWS account, the activity can look very similar. A developer knows their application best, and is best suited to identify which actions and permissions are required.

Below are steps to take in order to completely tackle role shopping. From investigating application role activity through updating or building out new appropriately scoped roles.

Step 1: Correlate Application Activity with Tagging

In order to decouple role usage, the first step is to understand what applications are using which roles within an AWS Account. This will be an easier task if a cloud environment has adopted tagging best practices. It’s important to use tags consistently across all of your resources, where supported^{2 3}. In AWS, you have the luxury of applying multiple tags to a resource, and it is a best practice to have a standardized tagging strategy across your AWS accounts.⁴ Applying application-identifying tags to every resource helps build the chain of ownership for investigating which application is represented by which actions in AWS CloudTrail. You will almost always have the Resource Name in a CloudTrail event⁵. Automation and analytics can help you query and correlate identifying tags with role activity.

Step 2: Create Application Activity Profiles

Once you can correlate role activity to a given application, you can start building a profile of activity - permissions and resources that are unique to the application. For a shopped role, this is often a subset of the permissions currently granted to a role. To the extent you have retained historic CloudTrail logs, the world is your oyster for mapping this activity. Unfortunately, there are some AWS API calls which are not captured in CloudTrail activity, so while this will help you form a thorough picture, it will not be a perfect one. The activity profile will bring application permission profiling within one play of the finish line.

Step 3: Build IAM Policy Sets and Unique Roles for Each Application

With application activity profiles in hand, the groundwork is set to build new IAM policies where you apply the principle of least privilege⁶. Start with a minimum set of permissions and grant additional permissions as necessary.⁷ Each application should have its own unique role, with unique permissions for its intended behavior and no more. It is recommended to periodically audit application activity in CloudTrail to verify if privileges have creeped over time. If there are new permissions which have not been used within a reasonable period⁸, consider downscoping the individual IAM Policies. This will be much easier with at least a unique role for every application! Depending on the behavior of that application, consider what the longest recurring activity is and base periodic investigation on that timeframe. If an application re-deploys a resource every quarter it is important to look back at least 90 days to capture that behavior.

Step 4: Retire Old Role Shopped Roles

Once you have built new roles uniquely for each application, consider testing the successful elimination of the old roles. Attaching an IAM Policy with Deny permissions for ‘Resource’ : ‘*’ can simulate deleting a role. However, detaching a policy is less permanent than deleting a role which makes for good testing practices. Retiring and removing the role entirely gives the comfort of certainty that the role can no longer be used by multiple applications.

Role Shopping can be avoided entirely if AWS Accounts are each limited to one application. Isolating applications and workloads at an AWS Account level will ensure permission creep cannot happen in the first place.⁹ Understanding multiple applications requires a depth of business and organizational knowledge in addition to the technical ability to rebuild permission sets. It can be a long journey to clean up and achieve a well architected permissions model, but it is well worth the security and operational risk mitigation.

Thanks to @Dustin Whited, @Jason Dyke, and @Ilan Ponimansky for their editor contributions.