Why env0
Solutions
Infrastructure as Code (IaC) Automation Teams and GovernanceManaged Self-Service env0 for the Enterprise
DocumentationPricing
Resources
Case StudiesIn the NewsVideosWebinars
Blog
Login
Get a Demo
FREE TRIALContact us
Nov 14, 2022

How to Implement fine-grained Role-Based Access Control for Your Infrastructure as Code with Custom RBAC Roles

Kevin "KMac" Damaso
Technical Product Marketer

How do you manage access permissions for your Infrastructure as Code deployments? A common challenge with modern implementations of IaC platforms is the lack of fine-grained Role-Based Access Control (RBAC). This leads to project sprawl and the need to give too many users far too permissive roles, posing security and operational risks.

Today we're announcing the launch of Custom RBAC Roles to solve this issue by providing env0 users with granular RBAC that enables ultimate flexibility and control over who can do what within your Infrastructure as Code projects.

We've designed Custom RBAC Roles as a “list of permissions” rather than as a “rule engine,” to ensure an approachable experience with a quick learning curve—no need to learn Rego or another language to write permissions. Plus, we’ve got plenty of documentation and support available to help you get up to speed quickly.

Granular RBAC functionality has been highly requested by some of our customers. Let’s explore the purpose of role-based access control and why it’s important.

The principle of least privilege: why granular Role-Based Access Control (RBAC) is critical to Infrastructure as Code

I was recently at DevOps Days Chicago, where Hannah Sutor did a talk on the Principle of Least Privilege (POLP): an essential concept in security which states that each user should only have the permissions absolutely necessary for their responsibilities.

The primary way to achieve this is through RBAC, which allows you to assign specific roles to users, and then grant or deny access based on those user roles. This granular level of control prevents any one user from having too much control over your infrastructure, reducing potential vectors for attack.

We developed Custom RBAC Roles in response to what we’ve been hearing from customers. Here’s one example:

 “Ad Hoc tasks are great. Can we have more roles than user and admin to make the feature usable without having to give full access to many users?”

So we performed an audit of current solutions and found that some RBAC systems only offer the following basic role assignments for access management:

  • User has read access to a stack
  • User has write access to a stack (this pretty much includes everything)
  • User can approve a deploy
  • User can run a task

These role assignment policies aren’t really all that granular, and don’t offer the fine-tuned controls needed by sophisticated DevOps teams. And often, this broad RBAC delivers mutually exclusive roles that can block developers from creating or modifying the infrastructure they need to provision.

How important is granularity within RBAC?

Lack of granularity in role permissions leads to users having too high or too low a level of access. Too little access creates dependencies that eat into precious dev time. Too much access creates security risks.

Enter Custom RBAC Roles.

New fine-grained RBAC design through env0 custom roles

In the spirit of continuous improvement, we’re delivering the following highly requested permissions:

  • Edit Module Registry
  • View Dashboard
  • Run Ad Hoc tasks
  • Create/Edit Project Templates
  • Creating an environment from VCS\Abort button
  • Abort button

And we have plans for the following in a future release:

  • Environment ownership
  • Ability to define different permissions for environment owner
  • Ability to change ownership of an environment
  • Multiple environment owners
  • Each lab owner should see only their lab in the project
  • RBAC by environment

All of these are in addition to the simple four-role model that we have today.

To combat over-engineering and over-complicating permissions, we're giving users a short list to enable DevOps teams to start as lean as possible, but be expandable to more and more (and even more) permissions as your needs become more defined.

We've mapped out all of the actions that a user can take in env0, and categorized them into the following buckets:

  • Organization user
  • Project viewer
  • Project planner
  • Project deployer
  • Project admin
  • Organization admin
  • Custom roles

This breakdown should help you understand what kinds of tasks each role should be responsible for, while giving the flexibility to define specific roles unique to your organizational needs.

Role-Based Access Control example | RBAC Best Practices

Step 1: Create a role

In our example we want team members to be able to request environment deployments of templates that are not necessarily on their project. We also want the group leader to be able to approve their environments’ deployments.

We’ll start by creating a new role for the team members.We go to Organization Settings -> Roles -> “Add Role” and select the following permissions:

View Project - So they can view the projectRun Plan - So they can plan and run environments that will require approvals

Manage Project Templates - So that they can pick from existing templates & add them to their project (thus being able to request environments based on these templates without an admin needing to assign these templates to their project)

Now lets create the deployment approver role, we’ll give it all the permissions we gave the “Team Member” role and include the “Run Apply” permission (so that he can approve plans)


When you finish you should have two roles like so
‍

Step 2: Assign the role

We recommend utilizing teams to assign roles, that way you can easily add and remove users from a teams instead of having to assign the roles to each individual user ( teams & users are assigned to projects, so instead of assigning a user to a project and assign him a role for that project you can just do it once for a team, and assign/unassign users to/from that team)

For the sake of our example let's say we have 2 projects: Project Alpha & Project Beta.

And that each has its own team: Team Alpha & Team Beta.

Each team has a team member we’ve decided will act as an approver: Alpha’s is Asher, Beta’s is Amy.

In order to finish up our setup we just need to assign each team and approver their desired role on the relevant project. ( note: if we had multiple approvers per project we could have just created a team for deployment approvers as well).

We do this by going to our Project -> Project Settings -> Teams
And assign the role we’ve created earlier like so:


‍
And lets not forget our approvers:
Project -> Project Settings -> Users


‍

And we’re done.

Each team member can run plans only in their teams project, and Asher & Amy can approve plans made by their team members.

When a new team member joins or another leaves we simply assign/unassign them from the team in Organization Settings -> Team -> People Icon Button.

Why you should use env0 custom roles for granular RBAC

Granular RBAC is essential for Infrastructure as Code because it allows you to give each user only the permissions they need to do their job, nothing more. This reduces the potential attack surface of your infrastructure and helps to prevent accidental changes that could break things.

In a world where infrastructure is constantly changing and evolving, it's more important than ever to have tight controls over who can make what changes. Try Custom Roles today and see how easy it is to implement infrastructure access that satisfies your governance and compliance requirements.

To get started with Custom Roles, head over to our docs site and check out the quick start guide. Then take a look at the other features and capabilities that env0 offers to help you streamline your Infrastructure as Code deployments.

Interested in learning more about env0?
Request a Demo
SHARE
You may also like
Day 0 Environment Creation
Share outputs between IaC stacks
Chris' Corner - March 2023
Go back to blog
CNCF Member Badge
Company
About UsIn the NewsPress ReleasesCase StudiesAdditional ResourcesCareers
Developer and DevOps
APITerraform ProviderTerratag Open Source
Terraform Cloud AlternativeDIY AlternativeAtlantis Alternative
FREE TRIAL
Follow Us
Terms of ServicePrivacy PolicySecuritySystem Status
© Copyright env0 2023
This website uses cookies. We use cookies to ensure that we give you the best experience on our website. Learn More
PreferencesDenyAccept
Privacy Preference Center
When you visit websites, they may store or retrieve data in your browser. This storage is often necessary for the basic functionality of the website. The storage may be used for marketing, analytics, and personalization of the site, such as storing your preferences. Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website.
Reject all cookiesAllow all cookies
Manage Consent Preferences by Category
Essential
Always Active
These items are required to enable basic website functionality.
Marketing
These items are used to deliver advertising that is more relevant to you and your interests. They may also be used to limit the number of times you see an advertisement and measure the effectiveness of advertising campaigns. Advertising networks usually place them with the website operator’s permission.
Personalization
These items allow the website to remember choices you make (such as your user name, language, or the region you are in) and provide enhanced, more personal features. For example, a website may provide you with local weather reports or traffic news by storing data about your current location.
Analytics
These items help the website operator understand how its website performs, how visitors interact with the site, and whether there may be technical issues. This storage type usually doesn’t collect information that identifies a visitor.
Confirm my preferences and close