Harness Delivers RBAC For Continuous Delivery

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.

Flexible Modeling of Orgs and Teams

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.

Role-Based Access Control Granular Permissions

Customers requested infinite granularity of permissions across the different components of their deployment pipelines.

Harness allows permissions for:

• Applications - logical group of services
• Services - artifacts
• Environments - infrastructure
• Triggers - condition to execute pipelines/workflows
• Pipelines - set of stages/workflows
• Workflows - deploys service(s) to an environment
• Deployments - execution of a pipeline/workflow

Actions can then be mapped to each of the above.

Full Separation of Duties (Actions) With Role-Based Access Control

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:

• Create
• Update
• Delete
• Execute
• Read

Restrict Usage of Cloud Providers & Tools

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.

Role-Based Access Control Example For Continuous Delivery

Let's imagine we have the following teams in our organization:

• DevOps - responsible for CI/CD tooling and building deployment pipelines (automation) across all apps
• eCommerce - responsible for developing and deploying the front-end web application
• Payment - responsible for developing and deploying payment microservice
• Order - responsible for developing & deploying order microservice
• Exec - responsible for the delivery of eCommerce

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:

Let DevOps Build Deployment Pipelines

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.

Let Development Deploy using Deployment Pipelines

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.

Let Executives Get Insight Across Pipelines

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.

Restricting Cloud Account & Tools Access For The Teams

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.

Cheers,
Steve.
@BurtonSays