> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control.md). # Platform Access Control Control access to resources through roles, resource groups, and user assignments across account, organization, and project scopes. Role-based access control (RBAC) controls who can access your resources and what actions they can perform on those resources. A Harness account administrator assigns resource-related permissions to members of user groups through roles and resource groups. RBAC helps you ensure users can only access the information and resources necessary to perform their tasks, create systematic and repeatable permissions assignments, increase accountability through audit trails, and comply with regulatory requirements for confidentiality and privacy. *** ### What you will learn in this topic By the end of this topic, you will be able to: * [Understand the three-level permissions hierarchy (Account, Organization, Project)](#permissions-hierarchy-scopes). * [Configure RBAC components (Principals, Resource Groups, Roles)](#rbac-components). * [Assign roles and resource groups to users, user groups, and service accounts](#role-binding). * [Apply the additive RBAC model and principle of least privilege](#rbac-is-additive). * [Extend RBAC with Attribute-Based Access Control for fine-grained control](#extend-rbac-with-abac). *** ### Before you begin Before you configure RBAC in Harness, ensure you have the following: * **Harness key concepts**: Understanding of Harness platform fundamentals. Go to [Key concepts](/service-reliability-management/new-to-srm/get-started/key-concepts.md) to learn about core platform concepts. * **Organizations and projects**: Knowledge of how to create and manage organizations and projects. Go to [Create an organization](/harness-platform/new-to-harness-platform/get-started.md#create-an-organization) to learn about organizational structure. * **Module functionality**: Familiarity with the modules you use in your Harness account (CI, CD, CCM, STO, etc.). * **Account admin access**: Administrator permissions to configure roles, resource groups, and user assignments at the account level. {% hint style="info" %} **RECOMMENDATION** If you are new to RBAC, review [User and Role Management in the Harness Software Delivery Platform](https://harness.io/blog/continuous-delivery/user-role-management/) for an introduction to RBAC concepts and best practices. {% endhint %} *** ### Overview video The video below provides an overview of RBAC in Harness. {% embed url="" %} *** ### Permissions hierarchy (scopes) Understand how Harness organizes permissions across three hierarchical levels to provide granular access control. 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 to delegate responsibilities to different teams and efficiently organize and manage your resources. 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 are not 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. ```mermaid flowchart TD A[Account] --> B(Organization) A[Account] --> C(Organization) B --> D[Project] B --> E[Project] C --> F[Project] C --> G[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. Go to [Create Organizations and Projects](/harness-platform/new-to-harness-platform/get-started.md#create-an-organization) to create and manage organizations and projects. *** **Scope matching for roles and resources** A role by itself grants nothing. Access comes from a role assignment, which combines a role, a resource group, and a principal at a specific scope. Two conditions must both hold for that assignment to grant access to a resource: * The role assignment's scope must be the resource's scope or an ancestor of it. Grants flow down the hierarchy, account to organization to project, never up. * The resource group in that assignment must cover the resource's scope, either directly or by including child scopes. This rule applies uniformly across resource types; there are no exceptions for connectors, secrets, templates, or service accounts. A connector created at the account scope requires a role assignment at the account scope (or an assignment with a resource group that includes child scopes). A **Project Admin** role at the project scope does not grant access to that connector, even if the project uses it, because the assignment's scope does not reach the connector's scope. {% hint style="warning" %} **ACCOUNT-SCOPED RESOURCES** If a user gets a permission error on a resource that is used in a project but was created at the account or organization scope, check the resource's scope and assign a role at that same scope, or a resource group that includes child scopes. {% endhint %} Harness does not warn at assignment time when a role assignment cannot reach a resource's scope. Assignment-time validation only checks that the role and resource group are scope-compatible with each other; it cannot know whether a given assignment was intended to reach lower scopes, so an assignment that does not reach a particular resource is a valid configuration, not an error. *** ### RBAC components Control access through three core components: Principals (who), Resource Groups (what), and Roles (actions). Harness RBAC uses **Principals**, **Resource Groups**, and **Roles** to control access: * [Principals](#principals) are entities taking action in the system. These include users, user groups, and service accounts. * [Resource groups](#resource-groups) define what objects can be acted on. Objects include organizations, projects, pipelines, connectors, users, and more. * [Roles](#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](#role-binding). Roles and resource groups assigned to user groups are inherited by the users in those user groups. ```mermaid flowchart TD A[Roles & Resource groups]-->C[User groups] A--->B A--->E[Service accounts] C-->B[Users] ``` #### 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](/harness-platform/use-harness-platform/platform-access-control/add-users.md): 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](/harness-platform/use-harness-platform/platform-access-control/add-user-groups.md): 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](#permissions-hierarchy-scopes). * [Service Accounts](/harness-platform/use-harness-platform/platform-access-control/add-and-manage-service-account.md): Service accounts are like API users. You assign roles and resource groups to service accounts. Service accounts also have one or more [API keys](/harness-platform/use-harness-platform/automation/api/add-and-manage-api-keys.md), 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](#permissions-hierarchy-scopes). Resource groups are assigned along with [roles](#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. Go to [Manage resource groups](/harness-platform/3.0/harness-platform-resources/platform-access-control/add-resource-groups.md) to create and manage resource groups. #### Roles Roles are sets of [permissions](/harness-platform/use-harness-platform/platform-access-control/permissions-reference.md) that allow or deny specific operations on objects (resources). Roles are applied together with [resource groups](#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. Go to [Manage roles](/harness-platform/use-harness-platform/platform-access-control/add-manage-roles.md) to create and manage roles. Roles are scope-specific and can be created at all [scopes](#permissions-hierarchy-scopes). *** ### Role binding Assign roles and resource groups to principals to grant permissions and access at any scope. Role binding refers to the process of assigning [roles](#roles) and [resource groups](#resource-groups) to [principals](#principals) (users, user groups, and service accounts). Role binding can be configured at all scopes. ```mermaid flowchart TD A[Roles & Resource groups]-->C[User groups] A--->B A--->E[Service accounts] C-->B[Users] ```
Built-in role binding configurations The following table describes the role bindings (permissions and access) that result from some combinations of built-in [roles](#roles) and [resource groups](#resource-groups). This table does not include module-specific built-in roles, such as CET Admin or Chaos Admin. | Role | Resource Group | Resulting role binding | | ------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account Admin | Account - All Resources Including Child Scopes | All permissions on all resources in the account and resources in organizations and projects under the account. | | Account Admin | All Account Level Resources | All permissions on all resources at the account level only. | | Account Viewer | Account - All Resources Including Child Scopes | View resources in the account and resources in organizations and projects under the account. | | Account Viewer | All Account Level Resources | View resources at the account level only. | | Organization Admin | Org - All Resources Including Child Scopes | All permissions on all resources in a specific organization and all projects under that organization. | | Organization Admin | All Organization Level Resources | All permissions on all resources in a specific organization only. | | Organization Viewer | Org - All Resources Including Child Scopes | View resources in a specific organization and resources in projects under that organization. | | Organization Viewer | All Organization Level Resources | View resources in a specific organization only. | | Project Admin | All Project Level Resources | All permissions on all resources within a specific project. | | Project Viewer | All Project Level Resources | View resources in a specific project. | | Pipeline Executor | All Project Level Resources | |
#### RBAC is additive Apply the principle of least privilege when assigning cumulative permissions. RBAC is an additive model. 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. {% hint style="warning" %} **NO EXPLICIT DENY** Harness RBAC has no explicit deny. A principal's access is the union of every grant from every role and resource group assignment that applies to them. This holds universally, across role stacking, resource group stacking, and scope inheritance. Assigning a second, more restrictive role or resource group never narrows access granted by a broader one; a resource group that does not select a resource simply never grants it, it does not revoke a grant from elsewhere. To limit a principal's access, remove or narrow the permissive assignment itself. {% endhint %} {% hint style="warning" %} **LEAST PRIVILEGE** 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. {% endhint %} 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 Apply attribute-based rules for highly refined access control on connectors and environments. For more fine-grained control over access to connectors and environments, you can use [Attribute-Based Access Control (ABAC)](/harness-platform/use-harness-platform/platform-access-control/attribute-based-access-control.md) 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. *** ### Troubleshooting
Permission error on an account-level resource despite having Project Admin A user with the **Project Admin** role gets an error accessing a connector, secret, or other resource that was created at the account scope, even though the resource is used in their project. The error looks identical to a genuine missing-permission error. It returns HTTP 403 with error code `NG_ACCESS_DENIED` and a message in the form `Missing permission on with identifier `, for example `Missing permission core_secret_view on secret with identifier mySecret`. Harness does not distinguish a scope mismatch from an actual missing grant in this message. This happens because Project Admin grants permissions only at the project scope. It does not extend to resources created at the account or organization scope, regardless of whether those resources are referenced inside the project. Go to [Scope matching for roles and resources](#permissions-hierarchy-scopes) for more information on why this happens. To resolve this, check the resource's scope and assign the user a role at that same scope, or a resource group that includes child scopes, instead of or in addition to the project-scoped role.
{% @harness-feedback/feedback module="harness-ai" pagePath="harness-ai/use-harness-platform/platform-access-control" %}