> 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 access for GitOps Applications using labels

Harness uses role-based access control (RBAC) for managing user permissions platform wide. This extends to Harness GitOps as well. To learn more, go to [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md)

In addition to regular controls, access to GitOps applications can be controlled via label-based RBAC. This topic will teach you how it works, and how you can use it.

### Before you begin <a href="#before-you-begin" id="before-you-begin"></a>

Ensure you are familiar with:

* [ApplicationSets](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/)
* [ApplicationSets at Harness](/continuous-delivery/use-gitops/applicationsets.md)
* [Harness Platform Access Control](/harness-ai/use-harness-platform/platform-access-control.md)

### Why use label-based RBAC? <a href="#why-use-label-based-rbac" id="why-use-label-based-rbac"></a>

Label-based RBAC offers several advantages:

1. **Granular Control**: Define permissions based on application characteristics rather than just names or namespaces.
2. **Scalability**: Easily manage permissions for large numbers of applications.
3. **Consistency**: Ensure uniform access policies across your entire application portfolio.
4. **Flexibility**: Adapt to changing organizational structures and application architectures without major RBAC overhauls.

### Implement label-based RBAC <a href="#implement-label-based-rbac" id="implement-label-based-rbac"></a>

#### Step 1: Define your labeling strategy <a href="#step-1-define-your-labeling-strategy" id="step-1-define-your-labeling-strategy"></a>

Before you start, define a consistent labeling strategy. For example:

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

#### Step 2: Update your Application <a href="#step-2-update-your-application" id="step-2-update-your-application"></a>

Next, add a label to your GitOps Application. To do so, follow these steps:

1. In your project, click **GitOps**.
2. Click **Applications**, and select your application.
3. In the options bar, select **App Details**.
4. Add a **Label** that is consistent with your labeling strategy.

**(Optional) Update your ApplicationSets**

Instead of modifying your application directly, you can also modify your existing [ApplicationSet templates](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/) to include the necessary labels. 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
```

#### Step 3: Create resource groups in Harness <a href="#step-3-create-resource-groups-in-harness" id="step-3-create-resource-groups-in-harness"></a>

Resource Groups in Harness allow you to group your applications. Here's how to create them:

1. Navigate to **Access Control** > **Resource Groups** in your **Project Settings**.
2. Click **New Resource Group**.
3. Name your group and click **Save**.
4. Select your **Resources** on the left. In this case you want **Gitops** > **Applications**.
5. Select **All** and click on **Save**

{% hint style="info" %}
You can also filter by labels by selecting **By Label** Click **Add** Add a label. Follow the labeling strategy you established in step 1. For example, a production application would have the label `harness.io/env-type: [prod|staging|dev]`. Click **Add Application Labels**.
{% endhint %}

### Step 4: Create a role with permissions <a href="#step-4-create-a-role-with-permissions" id="step-4-create-a-role-with-permissions"></a>

Now, create roles that have specific permissions you want your users to have for a given resource group.

1. Go to **Access Control** > **Roles** in your **Project Settings**.
2. Click **New Role**.
3. Name your role and click **Save**.
4. Update your role permissions. In this case, you want to scroll down to **GitOps** and enable the following permissions:
   * `VIEW`
   * `SYNC`

### Step 5: Bind roles and resource groups to users <a href="#step-5-bind-roles-and-resource-groups-to-users" id="step-5-bind-roles-and-resource-groups-to-users"></a>

Finally, assign the role and resource group you created to the [user](/harness-ai/use-harness-platform/platform-access-control/add-users.md) or [user groups](/harness-ai/use-harness-platform/platform-access-control/add-user-groups.md).

Once the binding is done, those users will be able to sync any applications that have the label you specified in the resource group in step 3!

### Harness Default Labels <a href="#harness-default-labels" id="harness-default-labels"></a>

When applications are generated through appsets, Harness will apply some labels to associated the application with services and environments. You can use these labels:

* `harness.io/envRef`: Enter the environment id. Use this to associate your application with a Harness Environment.
* `harness.io/serviceRef`: Enter the service id. Use this to associate your application with a Harness Service.

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

Common issues and solutions:

1. If the sync operation failed due to permissions issues:
   * Check the user's role assignments in Harness.
   * Verify application labels match the resource group filters.
2. If the labels are not applying correctly:
   * Ensure your PR pipeline scripts are executing correctly.
   * Check for conflicts in your ApplicationSet definitions.
3. If production changes bypass controls:
   * Verify your Git hooks are installed and executable.
   * Review your branch protection rules in your Git repository settings.