Ever have admin/admin login info syndrome? This may work fine for your monitoring tool, but it ain't going to work for Continuous Delivery. As an example, DevOps/TechOps need to manage tooling, Developers need the freedom to deploy, and security needs the ability to control this access so they can audit deployments for governance and compliance reasons. Role-Based Access Control (RBAC) is, therefore, a mandatory requirement for enterprise CD.
Around September last year, we sat down with several Harness customers to discuss our on-premises version and RBAC. This is what we learned.
Every business, organization, and application is different. Roles and responsibilities across teams also vary, especially when comparing traditional application architectures with cloud-native architectures.
For example, a microservices architecture will typically have multiple teams who each develop and deploy independently. You, therefore, need to model these roles within your CD platform to ensure everyone can deploy happily with the correct permissions and access rights. A typical enterprise may have several thousand applications, microservices (and teams).
In Harness, a user belongs to one or more user groups:
User groups are created by Harness admins and are defined by permissions and actions, both of which can be layered and filtered.
Customers requested infinite granularity of permissions across the different components of their deployment pipelines.
Harness allows permissions for:
Actions can then be mapped to each of the above.
It goes without saying that you want to control who can do what across your CD platform and deployment pipelines.
For example, you might want to let your DevOps team manage deployment pipelines (create/update/delete/read) but only allow Developers to deploy and view them. In addition, you might want to grant read-only access to execs so they can get visibility across your deployment pipelines.
These are the actions we agreed with our customers:
Continuous Delivery doesn't work without deployment pipelines accessing your cloud providers (or on-prem infra) and DevOps tools.
The challenge for many of our customers was restricting who could use what cloud accounts and toolsets. For example, you don't want several hundred people using the same AWS account for all apps/services/environments, and spinning up thousands of compute nodes as they wish. In addition, enterprises have many instances of Nexus, Jenkins, Splunk, ELK, AppDynamics and so on.
We solved these requirements by restricting Clouds & Tools at the application and environment level:
Applications and environments can also be layered so many apps/environments can relate to a single Cloud Provider or tool instance.
Let's imagine we have the following teams in our organization:
Here's a quick 3-minute video on how to create these teams:
In Harness, click the Continuous Security navigation header, and select Users and Permissions:
Using Role-Based Access Control in Harness, we can create a DevOps user group with the following permissions:
In the above screenshot, our DevOps user group is granted permissions to build (create, update, delete, read) deployment pipelines for all applications, services, and environments, but cannot deploy using them. The deployment permission is reserved and granted to each dev team so they're able to read and execute deployment pipelines built by DevOps.
For example, the eCommerce development team user group looks like this:
Application and Services have been filtered to "eCommerce" only. Actions have also been restricted to "execute" and "read" so the team can deploy using the environment, workflow, and pipelines that the DevOps team has built for them. Obviously, Harness permissions and actions are flexible so you can personalize them to the needs of your own org and teams.
Lastly, we can grant execs with read-only access to all "eCommerce" apps/services and deployment pipelines:
This gives execs the ability to access analytics and reports across all deployment pipelines.
In addition to Role-Based Access Control, we'll be shipping LDAP/AD/OKTA/SAML support very shortly so you can then authenticate users and map user groups between your corporate directories and Harness.
Feel free to signup for your free trial of the Harness software delivery platform and give it a shot.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.