# 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 define **different** scopes for each data entity (logs, traces, events, workloads, etc.).
   * 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.

***

**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.

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


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

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

The question should be specific, self-contained, and written in natural language.
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.