Role-based access control (RBAC) in Harness
Role-based access control (RBAC) lets you control who can access your resources and what actions they can perform on the resources. To do this, a Harness account administrator assigns resource-related permissions to members of user groups.
Using RBAC helps you:
- Ensure users can only access the information and resources necessary to perform their tasks. This reduces the risk of security breaches and unauthorized access to sensitive data.
- Create systematic, repeatable permissions assignments. RBAC saves time and increases efficiency for administrators who otherwise have to manage access for individual user accounts. You can quickly add and change roles, as well as implement them across APIs.
- Increase accountability by clearly defining who has access to which resources and information. This makes it easier to track and audit user activities, helping to identify and prevent misuse or abuse of access privileges.
- More effectively comply with regulatory and statutory requirements for confidentiality and privacy. It helps you enforce privacy and data protection policies.
If you're not familiar with RBAC, check out this blog post on User and Role Management in the Harness Software Delivery Platform.
Before configuring RBAC in Harness, you should have an understanding of:
- Harness' key concepts.
- Creating organizations and projects.
- The functionality of the modules in your Harness account.
The video below gives an overview of RBAC in Harness.
Permissions hierarchy (scopes)
The Harness Platform has a three-level hierarchical structure. The three levels, or scopes, are Account, Organization (Org), and Project.
You can configure permissions for each scope. This helps you delegate responsibilities to different teams and efficiently organize and manage your resources by providing granular access control that is flexible, scalable, and easy to manage.
The Account scope is the highest level. It is your Harness account and it encompasses all the resources within your Harness subscription. It provides a way to manage billing, user authentication, and global settings for all the organizations and projects within the account. Users with account-level permissions can manage the account-level settings, including billing, subscription, and SSO configuration. Resources, such as connectors, created at the account scope are available for use in all the organizations and projects within that account.
The Organization scope contains related projects, resources, and users within a specific domain or business unit. It provides a way to manage resources and permissions specific to a particular organization, as separate from other areas of the account. Users with org-level permissions can manage organization-level settings, including the creation of projects and user groups in the org, and assigning access policies to those user groups. Resources created at the organization scope are available for use in all projects within that organization, but aren't available outside that org.
The Project scope contains related resources, such as apps, pipelines, and environments. It provides a way to manage resources and permissions specific to a particular project, as separate from the larger org (business unit) and account. Users with project-level permissions can manage project-level settings, including the creation of pipelines, environments, and infrastructure definitions. Resources created at the project scope are only available in that project.
The scope at which you create resources depends on the level of control and visibility you require. For example, if you create a connector at the account scope, it is available to all organizations and projects within the account. However, if you create a connector at the organization scope, it is only available to that organization and any projects under that organization. It is not available at the account scope or to other organizations. This lets you control access to your resources more effectively and prevent unauthorized access.
To learn about organizations and projects, go to Create Organizations and Projects.
RBAC components
Harness RBAC uses Principals, Resource Groups, and Roles to control access.
- Principals are entities taking action in the system. These include users, user groups, and service accounts.
- Resource groups define what objects can be acted on. Objects include organizations, projects, pipelines, connectors, users, and more.
- Roles define what actions can be taken on objects. Actions include view, create, edit, delete, and so on.
You assign roles and resource groups to principals. Roles and resource groups assigned to user groups are inherited by the users in those user groups.
Principals
Principals are entities taking action in the system. You assign permissions and access, through roles and resource groups, to principals. Permissions define what actions a principal can take. Access defines which objects they can act on.
Principals include:
- Users: Individual users in Harness. Each user can belong to many user groups. You can assign roles and resource groups directly to users, or they can inherit these from user groups that they belong to.
- User Groups: User groups contain multiple Harness users. Roles and resource groups are assigned to groups. The permissions and access granted by the assigned roles and resource groups are applied to all group members. You can create user groups at all scopes.
- Service Accounts: Service accounts are like API users. You assign roles and resource groups to service accounts. Service accounts also have one or more API keys, which authenticate and authorize remote services attempting to perform operations in Harness through Harness APIs.
Resource groups
A resource group is a set of Harness resources that a principal can access. You can create resource groups at all scopes. Resource groups are assigned along with roles to principals. Roles grant permissions (what actions can be taken) and resource groups grant access (what objects can be acted on).
Resource groups either include All Resources (all resources of a given type) or Named Resources (specific, individual resources).
Harness has built-in resource groups at each scope, and you can create custom resource groups. For more information, go to Manage resource groups.
Roles
Roles are sets of permissions that allow or deny specific operations on objects (resources). Roles are applied together with resource groups to create a complete set of permissions and access.
Harness includes some built-in roles, and you can create your own custom roles, which are useful for limited and fine-grained access control. For more information, go to Manage roles.
Roles are scope-specific and can be created at all scopes.
Role binding
Role binding refers to the process of assigning roles and resource groups to principals (users, user groups, and service accounts). Role binding can be configured at all scopes.
Built-in role binding configurations
RBAC is additive
RBAC is an additive model; therefore, role and resource group assignments in Harness are additive. The total expanse of a principal's permissions and access is the sum of all the roles and resource groups from all user groups they belong to, as well as any roles and resource groups assigned directly to them as an individual user or service account.
It is important to follow the principle of least privilege (PoLP). This is a security principle that means users are granted the absolute minimum access/permissions necessary to complete their tasks and nothing more.
While Harness includes some built-in roles and resource groups, it is a good idea to create your own roles and resource groups as needed to ensure the least privilege.
For example, assume a user has these role and resource group assignments:
- Account Admin role with All Resources Including Child Scopes. This is the most permissive combination of role and resource group. It grants all permissions on all resources throughout the entire account.
- Organization Viewer role with All Resources Including Child Scopes. This combination, by itself, grants the ability to view resources in a specific organization and resources in the projects under that organization.
Because the Account Admin combination includes the Org Viewer combination (and more), the user is effectively an account admin throughout the entire account. Assigning the Org Viewer role makes no difference to this user's access.
To control this user's access, you could change the resource group for the Account Admin role to All Account Level Resources. This would limit the Account Admin permissions to the resources at the account level only and remove admin access to lower scopes.
Extend RBAC with ABAC
For more fine-grained control over access to connectors and environments, you can use Attribute-Based Access Control (ABAC) as an extension of RBAC on your resource groups.
ABAC provides highly refined control by using rules to restrict access based on combinations of attributes, such as connector and environment type.
Configure RBAC in Harness
Before configuring RBAC in Harness, make sure you understand the RBAC components and role binding.
Required permissions
To configure RBAC in Harness, you must be an admin in the relevant account, organization, or project.
If your Harness account is new, you might need to contact Harness Support to get the first admin provisioned in your account.
If you are not an admin, you can configure some aspects of RBAC if you have the required granular permissions:
- Users: Requires View, Manage, and Invite permissions for Users.
- User groups: Requires View and Manage permissions for User Groups.
- Resource groups: Requires View, Create/Edit, and Delete permissions for Resource Groups.
- Roles: Requires View, Create/Edit, and Delete permissions for Roles.
RBAC workflow summary
To configure RBAC in Harness, you must:
- Create roles.
- Create resource groups and, optionally, apply ABAC.
- Create user groups, create service accounts, and add users.
- Assign roles and resource groups to users, user groups, and service accounts.
- If you have not already done so, configure authentication.
You can create users and user groups directly in Harness, and you can use automated provisioning, including:
With automated provisioning, users and user groups are imported from your IdP, and then you assign roles and resource groups to the imported principals in Harness. You manage group metadata, group membership, and user profiles in your IdP, and you manage role and resource group assignments in Harness.
You can also create users and user groups directly in Harness, but any users or groups imported from your IdP must be managed in your IdP. For imported users and group, you can only change their role and resource group assignments in Harness.
RBAC workflow examples
These examples walk through two specific RBAC configuration scenarios.