> 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/continuous-delivery/use-gitops/application/manage-permissions.md).

# Manage GitOps Application Access with Labels

Configure label-based role-based access control (RBAC) to control which GitOps applications each user can view and sync

Harness uses role-based access control (RBAC) across the platform, including GitOps. In addition to standard RBAC, you can restrict access to GitOps applications using labels on those applications. The GitOps application list shows only the applications each user is authorized to access based on label-based RBAC.

***

## What you will learn from this topic

* **Label-based RBAC:** How Harness matches application labels to resource groups and roles.
* **Labeling strategy:** How to define labels that scale across many applications.
* **Resource groups and roles:** How to create resource groups, assign GitOps permissions, and bind roles to users.
* **Harness default labels:** Which labels Harness applies automatically and how to use them in resource groups.

***

## Before you begin

Review these topics before you configure label-based RBAC:

* **ApplicationSets:** Go to [ApplicationSet basics](/continuous-delivery/use-gitops/applicationsets/appset-basics.md) to understand how ApplicationSets generate applications.
* **Harness ApplicationSets:** Go to [ApplicationSets](/continuous-delivery/use-gitops/applicationsets.md) to review Harness ApplicationSet workflows.
* **Harness RBAC:** Go to [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md) to understand roles, resource groups, and role bindings.

***

## Why use label-based RBAC?

Label-based RBAC gives you finer control than name- or namespace-based permissions alone. The main benefits are:

* **Granular control:** Define permissions from application characteristics instead of individual application names.
* **Scalability:** Manage access for large application portfolios without one-off role assignments.
* **Consistency:** Apply uniform access policies across teams and environments.
* **Flexibility:** Adapt to organizational changes without rebuilding your entire RBAC model.

## Implement label-based RBAC

The following walkthrough configures label-based access from labeling strategy through role binding.

{% stepper %}
{% step %}

### Define your labeling strategy

Before you add labels, define a consistent strategy your teams can follow. For example:

* `harness.io/env-type: [prod|staging|dev]`
* `harness.io/team: [frontend|backend|data]`
* `harness.io/criticality: [high|medium|low]`
  {% endstep %}

{% step %}

### Add labels to your application

Add labels that match your strategy on each GitOps application, or generate them from an ApplicationSet template.

**Add a label on an existing application**

In your project, do the following:

1. Click **GitOps**.
2. Click **Applications**, then select your application.
3. On the options bar, select **App Details**.
4. Add a **Label** that matches your labeling strategy.

**Add labels through ApplicationSet templates**

Instead of labeling each application manually, add labels in your [ApplicationSet template](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/). For example:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-apps
spec:
  generators:
  - list:
      elements:
      - name: app1
        env: prod
        team: frontend
      - name: app2
        env: dev
        team: backend
  template:
    metadata:
      name: '{{name}}'
      labels:
        harness.io/env-type: '{{env}}'
        harness.io/team: '{{team}}'
    spec:
      # ... rest of your application spec
```

{% endstep %}

{% step %}

### Create resource groups in Harness

Resource groups let you scope GitOps applications by label.

1. In **Project Settings**, navigate to **Access Control** > **Resource Groups**.
2. Click **New Resource Group**.
3. Enter a name, then click **Save**.
4. On the left, select **Resources**, then select **GitOps** > **Applications**.
5. Select **All**, then click **Save**.

{% hint style="info" %}
**Filter by label**

To scope a resource group to specific applications, select **By Label**, click **Add**, enter a label from your strategy (for example, `harness.io/env-type: prod`), then click **Add Application Labels**.
{% endhint %}
{% endstep %}

{% step %}

### Create a role with permissions

Create a role that grants the GitOps permissions users need on applications in the resource group.

1. In **Project Settings**, navigate to **Access Control** > **Roles**.
2. Click **New Role**.
3. Enter a name, then click **Save**.
4. Under **GitOps**, enable **View** and **Sync** (or the permissions your workflow requires).
   {% endstep %}

{% step %}

### Bind roles and resource groups to users

Assign the role and resource group to the users or groups who need access.

1. In **Project Settings**, navigate to **Access Control** > **Role Bindings**.
2. Create a binding that maps your role and resource group to a [user](/harness-ai/use-harness-platform/platform-access-control/add-users.md) or [user group](/harness-ai/use-harness-platform/platform-access-control/add-user-groups.md).

After the binding is in place, those users can sync applications that match the labels in the resource group.
{% endstep %}
{% endstepper %}

## Harness default labels

When Harness generates applications from ApplicationSets, it can apply default labels that associate applications with Harness services and environments. You can use these labels in resource group filters:

* `harness.io/envRef`: Enter the environment identifier to associate the application with a Harness environment.
* `harness.io/serviceRef`: Enter the service identifier to associate the application with a Harness service.

***

## Troubleshooting

<details>

<summary>Sync operation fails because of permissions</summary>

Confirm the user has a role binding that includes **Sync** on GitOps applications. Verify that application labels match the label filters on the resource group in the binding.

</details>

<details>

<summary>Labels do not appear on applications</summary>

Confirm your ApplicationSet template includes the labels in `template.metadata.labels`. If you add labels through a pipeline, verify the pipeline step runs successfully and that no conflicting ApplicationSet definitions overwrite the labels.

</details>

<details>

<summary>User cannot see expected applications in the GitOps application list</summary>

Check the user's role bindings and confirm the resource group label filters include the labels on the application. Users only see applications that match their authorized resource groups.

</details>

***

## Next steps

You configured label-based RBAC for GitOps applications. Extend access control and application management with these topics:

* [Manage GitOps applications](/continuous-delivery/use-gitops/application/manage-gitops-applications.md): View, sync, and manage individual applications.
* [ApplicationSets](/continuous-delivery/use-gitops/applicationsets.md): Generate labeled applications at scale.
* [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md): Review platform-wide access control patterns.

{% @harness-feedback/feedback %}