Access Management (RBAC) Overview
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
- Defining and assigning permissions
- Defining permissions using Roles
- Role Assignment
- Permissions Are Additive
- Next Steps
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.
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.
The below table shows the corresponding Role Bindings at each scope:
Roles and Permissions
Auth_Manager - View, Create/Edit, Delete Authentication Settings at Account scope.
Delegate_Creator - Create/Edit Delegates at the scope of Org1.
Connector_Creator - Create/Edit Connectors at the scope of Org2.
Pipeline_Executor - Execute Pipelines at the scope of this Project.
Secret_Creator - Create/Edit Secrets at the scope of this Project.
Service_Creator - Create/Edit Services at the scope of this Project.
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.