> For the complete documentation index, see [llms.txt](https://docs.groundcover.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.groundcover.com/administer/role-based-access-control-rbac.md).

# Role-Based Access Control (RBAC)

{% hint style="info" %}
This capability is only available to organizations subscribed to our [Enterprise plan](https://www.groundcover.com/pricing).
{% endhint %}

Role-Based Access Control (RBAC) in groundcover gives you a flexible way to manage who can access certain features and data in the platform. By defining both **default roles** and **policies**, you ensure each team member only sees and does what their level of access permits. This approach strengthens security and simplifies onboarding, allowing administrators to confidently grant or limit access.

{% embed url="<https://www.youtube.com/watch?v=HMDAcYCxMfc>" %}

### Policies

Policies are the **foundational elements** of groundcover’s RBAC. Each policy defines:

1. A **permission level** – which actions the user can perform (Admin, Editor, or Viewer-like capabilities).
2. A **data scope** – which clusters, environments, or namespaces the user can see.

By assigning one or more policies to a user, you can precisely control **both** what they can do **and** where they can do it.

#### Default Policies

groundcover provides three **default policies** to simplify common use cases:

1. **Default Admin Policy**
   * **Permission**: Admin
   * **Data Scope**: Full (no restrictions)
   * **Behavior**: Unlimited access to groundcover features and configurations.
2. **Default Editor Policy**
   * **Permission**: Editor
   * **Data Scope**: Full (no restrictions)
   * **Behavior**: Full creation/editing capabilities on observability data, but no user or system management.
3. **Default Viewer Policy**
   * **Permission**: Viewer
   * **Data Scope**: Full (no restrictions)
   * **Behavior**: Read-only access to all data in groundcover.

These default policies allow you to quickly onboard new users with typical Admin/Editor/Viewer capabilities. However, you can also create **custom policies** with narrower data scopes, if needed.

#### Policy Structure

A policy’s **data scope** can be defined in two modes: **Simple** or **Advanced**.

1. **Simple Mode**
   * Uses **AND** logic across the specified conditions.
   * Applies the *same* scope to all entity types (e.g., logs, traces, events, workloads).
   * **Example**: “Cluster = `Dev` **AND** Environment = `QA`,” restricting **all** logs, traces, events, etc. to the Dev cluster and QA environment.
2. **Advanced Mode**
   * Lets you set a **separate scope per data type**, each enabled independently:
     * **Workload / Infrastructure**
     * **Logs**
     * **Traces**
     * **Events**
     * **Metrics** — also covers **ingestion** data (volume and measurements); there is no separate ingestion scope.
   * Each scope can use **OR** logic among conditions, allowing more fine-grained control.
   * **Example**:
     * **Logs**: “Cluster = `Dev` **OR** `Prod`,”
     * **Traces**: “Namespace = `abc123`,”
     * **Events**: “Environment = `Staging` **OR** `Prod`.”

When creating or editing a policy, you select **permission** (Admin, Editor, or Viewer) *and* a **data scope mode** (Simple or Advanced).

#### Multiple Policies

A user can be associated with **multiple** policies. When that occurs:

1. **Permission Merging**
   * The user’s final permission level is the **highest** among all assigned policies.
   * **Example**: If one policy grants Editor and another grants Viewer, the user is effectively an Editor overall.
2. **Data Scope Merging**
   * Data scopes merge via **OR** logic, broadening the user's overall data access.
   * **Example**: Policy A => "Cluster = `A`," Policy B => "Environment = `B`," so final scope is "Cluster A **OR** Environment B."
   * This applies to all data types including logs, traces, events, workloads, and metrics.

A user may be assigned a policy granting the Editor role with a data scope relevant to specific clusters, and simultaneously be assigned another policy granting the Viewer role with a different data scope. The user's effective access is determined by the highest role across all assigned policies and by the union (OR) of scopes.

#### Sensitive Data Access

A policy can also grant access to [sensitive attributes](/collect-data/data-pipelines/log-pipelines/sensitive-attributes.md), which are log attribute values masked for most users. Turn on **Allow access to sensitive data** in the policy's data scope section, or set `sensitiveAccess: true` through the API. Sensitive access is off by default for every policy, including the default ones. It applies only within the policy's logs data scope. When a user has several policies, only the scopes of policies that grant sensitive access are merged.

{% hint style="info" %}
The toggle for enabling sensitive data access will only be available once it was enabled in the backend. See [guide](/collect-data/data-pipelines/log-pipelines/sensitive-attributes.md) to enable it
{% endhint %}

***

**In summary:**

* **Policies** define both **permission** (Admin, Editor, or Viewer) and **data scope** (clusters, environments, namespaces).
* **Default Policies** (Admin, Editor, Viewer) provide no data restrictions, suitable for quick onboarding.
* **Custom Policies** allow more granular restrictions, specifying exactly which entities a user can see or modify.
* **Multiple Policies** can co-exist, merging permission levels and data scopes via OR logic across all data types.
* **Sensitive Data Access** is an opt-in per-policy flag that lets users reveal masked sensitive log attributes within the policy's logs scope.

This flexible system gives you robust control over observability data in groundcover, ensuring each user has precisely the access they need.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.groundcover.com/administer/role-based-access-control-rbac.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.