Skip to main content

Set Up RBAC for Application Release Process

This topic describes how to use Harness flexible RBAC for the very common Application Release Process scenario.

In this topic:

Before You Begin​

Review: Application Release Process and Roles​

Many organizations depend on RBAC to ensure compliance and consistency with application deployment. This topic describes a simplistic (minimal) approach by defining three groups associated with each application as follows:

User GroupRoleResponsibility
K8S_Deployer Application DeveloperDeploy Pipeline
K8S_DevOpsDevOps EngineerDesign and Implement Pipeline
K8S_ApproverApproverApprove Pipeline stages

This example uses a sample Harness Application named K8S to configure RBAC. The example suggests the creation of three user groups based on the roles and responsibilities of the users involved in the process.

  • Users in the Deployer group are allowed to only deploy but not to create or delete any Workflows or Pipeline.
  • DevOps users design and implement Workflows and Pipelines. Usually, a centralized team is responsible to create a reference Pipeline and Workflow that is compliant with the desired release process. DevOps engineers start with the clone of the reference Workflow and Pipeline and then adapt it to the application-specific requirements. For example, there are many steps that are skipped in a lower environment but mandatory in staging or production such as integrating with a change management system.
  • Users in the Approver group are usually Release managers or Application managers who approve or reject a Pipeline stage when promoting an application from the lower environment to staging or production.

The required permissions for the roles are as follows.

RoleResourcePermissions
DeployerPipelineRead, Execute Pipeline, Execute Workflow
DevOpsAll resourcesCreate, Read, Update, Execute Pipeline, Execute Workflow
ApproverPipelineRead

Step 1: Create the User Groups​

Create the three user groups as identified and defined already.

Create the K8S_Deployer Group​

Add a User Group with the name K8S_Deployer group. See Add a User Group for specific instructions.

The members of this Deployer Group need read access to the Environment, Services and Pipeline to allow Pipeline execution for the specific application—K8S. Set Account Permissions and Application Permissions to this user group as needed while adding the User Group.

This example shows that the Deployer Group is allowed access to both Non-Production and Production Environments. But, you can restrict access to the Production Environments by providing permission to only Non-Production Environments. This may be necessary in some organizations where the access to Production Environments is given only to a certain group/team.

The Deployer role does not have read access to Workflow. Users with this role can execute the Pipeline with just read access, but the users will not have access to view the Workflow steps.#### Create the K8S_DevOps Group

Add a User Group with the name K8S_DevOps group. See Add a User Group for specific instructions.

Assign the following permissions for full access to members of K8S_DevOps group for the K8S application except the Delete Application Permission.

DevOps users do not need full access like the Harness Administrator because they are only responsible for specific Applications. For example, it is a good practice not to assign the Delete Application Permission for this role. This allows Harness Administrators to be responsible for setting up the Application pre-configured with reference Workflows and Pipelines including RBAC setup. Users in the DevOps group can update/create new Services but cannot delete the Application. If the Application has to be deleted (if it is a sandbox application), the Harness Administrator should delete it.

Create the K8S_Approver Group​

Add a User Group with the name K8S_Approver group. See Add a User Group for specific instructions.

Assign the following Permissions to the members of the K8S_Approver group to allow them to approve or reject a Pipeline execution. The assumption is that these users log in into Harness to approve or reject. In many organizations, the decision to approve or reject is done externally via JIRA or a change management system such as Service Now. In such cases, this group is optional.

Step 2: Add Members to the Groups​

Add members to the three groups—K8S_Deployer, K8S_DevOps and K8S_Approver. See Add a User Group for specific instructions to add members to User Groups.

You can further refine the type of Permissions based on your organization roles and team structure to add additional groups or restrict access based on the Environment.

Next Steps​