Access Management (RBAC) Overview

Updated 1 month ago by Rashmi Nanda Sahoo

Harness provides Role-Based Access Control (RBAC) that enables you to control user and group access to Harness Resources according to their Role assignment.

In this topic:

Visual Summary

Here is an overview of Harness RBAC. It shows user authentication via its User settings and authorization via its User Group and Role Assignment.

Harness Access Control has the following components:

  • Principal: A principal can be a User, User Group or API Key. We assign Role Bindings to these and also refer to them as Subjects.
  • Users: these are individual users within the Harness system. One user can belong to many Accounts.

For more information on creating a new User, see Add and Manage Users.

  • User Groups: User Groups contains multiple Harness Users. Each User Group is assigned Roles. You can create User Groups at Account/Org/Project scope.
    For more information on creating a new User Group, see Add and Manage User Groups.
  • API Keys: These keys allow you to make authorized API calls to Harness. These can be created at the Account/Org/Project level.

For more information on creating a new User Group, see Add and Manage API Keys.

  • Resource Groups: a Resource Group is a set of Harness resources that a User or User Group can access. You can create Resource Groups at Account/Org/Project scope.

For more information on creating a new Resource Group, see Add and Manage Resource Groups.

  • Roles: a Role is a group of permissions you assign to a User Group. You can create Roles at Account/Org/Project scope.

For more information on creating a new Role, see Add and Manage Roles.

Defining permissions using Roles

You define permissions within a Role. A Role defines access to resources within a single scope — Project/Org/Account.

Role Assignment

You can grant Roles (group of permissions) to Users or User Groups and Service Accounts through Role Bindings. When an authenticated member attempts to access a resource, Access Control checks the role assignments to see if the action is allowed.

Access Control Overview

The below example considers a user, Example_User to explain how Access Control works in Harness. This user is a member of multiple user groups, each scoped at Account/Org/Project level.

  • User group Acc_UG, scoped at account Acc1.
  • User group Org1_UG, scoped at organization Org1. This org is created under Acc1.
  • User group Org2_UG, scoped at organization Org2. This org is created under Acc1.
  • User group Proj1_UG, scoped at project P1. This project is created under Org1.
  • User group Proj2_UG, scoped at project P2. This project is created under Org1.
  • User group Proj3_UG, scoped at project P3. This project is created under Org2.
By default, an Account Admin has the permissions to create Organizations scoped under it, and an Org Admin has the permissions to create Projects scoped under the Org.

The below table shows the corresponding Role Bindings at each scope:

User Group

Scope

Roles and Permissions

Resource Group

Acc_UG

Account

Auth_Manager - View, Create/Edit, Delete Authentication Settings at Account scope.

Authentication Settings

Org1_UG

Organization

Delegate_Creator - Create/Edit Delegates at the scope of Org1.

Delegates

Org2_UG

Organization

Connector_Creator - Create/Edit Connectors at the scope of Org2.

Connectors

Proj1_UG

Project

Pipeline_Executor - Execute Pipelines at the scope of this Project.

Pipelines

Proj2_UG

Project

Secret_Creator - Create/Edit Secrets at the scope of this Project.

Secrets

Proj3_UG

Project

Service_Creator - Create/Edit Services at the scope of this Project.

Services

Below is the visual summary of what the user can do in each scope:

Permissions Are Additive

When a Harness User is a member of two or more User Groups, that user's permission combines both User Groups' permissions.

By default, users would have View permissions for all resources at all scopes (Account/Org/Project).

Next Steps


Please Provide Feedback