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
- Step 1: Create the User Groups
- Step 2: Add Members to the Groups
- Next Steps
Before You Begin
- Review Managing Users and Groups (RBAC).
- Review application deployment and release process.
- Make sure you are member of the Harness Administrator Group.
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:
Design and Implement Pipeline
Approve 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.
Read, Execute Pipeline, Execute Workflow
Create, Read, Update, Execute Pipeline, Execute Workflow
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.
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.