A Role and Policy vending mechanism for generating baseline roles
Overview
In non-production AWS environments today, security and IAM are often deprioritized to increase velocity of development. This often results in all users being given administrator roles by default even though it is often unnecessary. To remediate this, Vertical Relevance’s Role Broker Module is a simple mechanism that takes a few parameters and automatically vends specifically tailored roles to enable teams to get proper permissions without affecting velocity.
Problem Statement
When it comes to security, organizations often focus their efforts on the security of the production environment. This is because fitting an environment with proper security processes and controls is time-consuming, can slow down development, and non-production environments are considered lower priority since they typically do not impact customers.
While it is true that customers don’t interact with non-production environments, that does not mean that the security best practices can be neglected, specifically when it comes to the first line of defense into the environment – Identity and Access Management (IAM). Without IAM Best Practices in place in lower environments, compromised credentials can lead to incredibly significant incidents such as leaked git credentials, the theft of proprietary code, and privilege escalation. Together, these consequences can ultimately result in malicious actors gaining an enhanced understanding of the lower environments which puts the production environment at risk.
To address this, the roles and policies in every environment must be carefully designed. With Vertical Relevance’s Role Broker you can automatically vend roles which are able to be much more granular than the AWS Administrator role, and more well fitting for individual job functions than AWS’s default roles.
Below is a matrix that outlines the three primary problems that are addressed by the Role Broker.
| Problem | Details |
| Difficulty of Secure Policy Creation | The complexity of IAM policies leads to many IAM administrators to make roles with wildcards for every action. Additionally, read-only roles are often poorly constructed and do not list all the necessary read-only actions needed for a job function |
| Insufficient AWS Default Roles | AWS Managed IAM Roles are not sufficient for individual job functions and are intended as a very brief starting point. However, many teams continue to use these as their environment matures past the intended point of use |
| Evolving Actions and Services within AWS | The IAM action list for each service is large and constantly expanding so it’s impossible to list them all correctly without programmatic means |
Organizations are currently addressing these issues with a variety of stopgap measures that are not viable long-term solutions. Existing strategies often include hiring dedicated personnel to create ideal roles for non-production environments, but this is costly, time-intensive, and prone to human-error. This also leads to a delay in the policy being written, whereas Vertical Relevance’s Role Broker generates the policy programmatically and is vended in real-time.
Solution
Vertical Relevance’s Role Broker was created as an alternative to the costly, error-prone strategies that many organizations use to manage their IAM roles in non-production environments. By leveraging the Role Broker, your organization will be able to quickly provide developers in lower environments with secure, properly scoped roles. The infrastructure for the Role Broker is created via CDK, and the actual roles and policies are created via Boto3 in a Lambda. This makes the infrastructure easy to deploy, low cost, and immediately ready for use.
Components
- Service Catalog – The frontend of the architecture is the Service Catalog product which vends the appropriately configured Lambda depending on the parameters specified by the user deploying the product
- S3 – This storage bucket is exclusively used for storing the Lambda function’s code in a consistent, stable, and secure location
- Lambda – The compute component behind this architecture is responsible for the calling of the Policy Sentry library to carefully define the properties of the IAM Policy and then compressing that list to work around the policy character limit
- Policy Sentry – This Python library is used for the collection of the full list of permissions related to each service and the requested access level
- IAM Policy – The IAM Role Broker’s primary functionality is the creation of the custom policy which limits a principal’s access to exclusively being within the confines determined
- IAM Role – The IAM Role created by the IAM Role Broker has the IAM Policy attached and is configured to work with the account principal
Implementation Details
Vertical Relevance’s Role Broker leverages Service Catalog to vend and trigger a Lambda function to create a role and policy based on the user’s input while launching the Service Catalog Product. The end-to-end flow of this process is illustrated in the diagram below.
Figure-01
Service Catalog acts as the front-end of the Role Broker. The Service Catalog product attaches 3 pieces of information to the Lambda creation CloudFormation template:
- AccessLevel
- What access level of role are you provisioning? (
Read,Write,List,Permisssions management, orTagging)
- What access level of role are you provisioning? (
- ActionCategory
- What category of resources does your role need access to? (
Kubernetes,Storage,Logging,IAM) - (More categories can be configured via the configuration JSON file)
- What category of resources does your role need access to? (
- RoleorPolicy
- Would you like a role and a policy generated, or just a policy? (
Role,Policy)
- Would you like a role and a policy generated, or just a policy? (
- TeamName
- What team’s resources does your role need access to? (
Security,QA,IAM) - (Any team name can be used, DevOps and IAM are simply examples)
- What team’s resources does your role need access to? (
The Lambda function, which is written in Python, takes the following steps to generate policies based on the user’s inputs.
- Iterates through the ActionCategory’s list of services (for example, the Storage team needs access to S3 actions)
- Leverages Policy Sentry to narrow down the list of permissions to be either read or write level of permissions
- Creates the permissions set via CDK to only allow these actions, on these services, with resources with the appropriate team’s tags
- Uses Boto3 to create the IAM Role and Policy resources based on the text of the policy is generated
An example policy made with the request of needing “Read” actions to the “DevOps” team’s “Storage” services can be seen below (abridged to include “Storage” as simply S3 related actions):
{
"Version": "2012-10-17",
"Statement": [
{
"Condition": {
"ForAllValues:StringEquals": {
"aws:ResourceTag/SupportTeam": "DevOps"
}
},
"Action": [
"s3:Describe*",
"s3:Get*",
],
"Resource": "*",
"Effect": "Allow"
}
]
}
More details regarding the deployment of this solution can be found in the Role Broker Repository on GitHub.
Deployment and Maintenance
Vertical Relevance’s Role Broker is intended to be deployed individually to every account which needs to utilize the module. Specifically, it is intended to be used in non-production environments since it is not intended to provide the ability to fine-tune the resource field in the policies it creates and it is not meant to circumvent the IAM validation processes that security teams have in place in Production environments. The Role Broker does not replace IAM or Security teams, but instead gives them time to focus on finetuning production-level roles for example, rather than frequently making new non-production environment roles, or skipping this task for the sake of time and giving too high a level of access.
To determine the mechanism for allowing workload accounts to consume the Role Broker, an organization’s Security Team should coordinate with the DevOps Team use the CDK code to deploy the Role Broker into the target workload accounts. To ensure each account can leverage the solution, we recommend integrating Role Broker deployment into the account vending and baselining process.
Summary
To remediate the complex, imperfect, and sometimes costly processes usually taken to create IAM policies and roles by hand, the Role Broker offers an automated approach to creating more tailored IAM Roles and Policies to be used in non-production environments. By utilizing the IAM Role Broker, organizations can have a least-privilege IAM strategy in non-production environments without having to endure high costs or sacrifice development agility.
Related Solutions
The Account Level Identity Foundations is a guide created for maintaining a strong identity platform at the account level, which includes prescriptive guidance around how AWS IAM’s components can be tied together to create a solid IAM baseline. Also included is a list of example roles which can be the first step to creating a greater list of roles- the next step for creating this greater list of roles was recommended to be the Role Broker.
