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.
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:
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.
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.
In the spirit of continuous improvement, we’re delivering the following highly requested permissions:
And we have plans for the following in a future release:
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:
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.
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
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.
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.
Use custom workflows to model any process
Visualize all IaC changes pre and post-deployment
Gain code-to-cloud visibility and governance
Improve developer experience and collaboration
Use custom workflows to model any process
Visualize all changes pre and post-deployment
Gain code-to-cloud visibility and governance
Improve developer experience and collaboration
env0 is the best way to deploy, scale, and manage your Terraform and other Infrastructure as Code tools.
.jpeg)
