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.
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.
.png)
