Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Faaa%2Faccess-control%2Fpolicies.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Faaa%2Faccess-control%2Fpolicies.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# Access policies

Policy-based access control gives you precise control over who can view, manage, or perform other supported actions on specific resources in Coralogix. It adds resource-level policies on top of your existing role-based permissions, so you can set rules per resource and per action instead of granting broad access to everyone who can access that resource type.

By combining access policies with groups, you can keep sensitive content private, create team-level silos, reduce dashboard and alert noise, personalize views, and make sure each team sees only what's relevant.

Use access policies to:

* Secure resource-level access for dashboards, datasets, alerts, Team API keys, and more.
* Streamline workflows by showing users only the resources they need.
* Reduce risk by limiting exposure to sensitive content using group-based rules.
* Enable secure collaboration across teams, managed service providers, or customers.

## How permissions and policies work together[​](#how-permissions-and-policies-work-together "Direct link to How permissions and policies work together")

* Role-based permissions determine whether a user can access a type of resource at all (for example, dashboards).
* Access policies fine-tune access for each individual resource (for example, a specific dashboard), including what actions a user or group can perform.

## Why use access policies[​](#why-use-access-policies "Direct link to Why use access policies")

| Team                          | How access policies help                                                                                             |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Admins and org owners         | Reduce data exposure, enforce least privilege, and support isolated team models for MSP and multi-team environments. |
| Security teams                | Protect sensitive content and enforce separation between teams or domains.                                           |
| DevOps and SRE                | Cut dashboard and alert noise by limiting visibility to owned resources.                                             |
| Developers                    | Work privately until ready to share, without changing role-based permissions.                                        |
| Data and observability admins | Restrict access to specific datasets and other high-impact resources.                                                |

## Understand policy-based access control[​](#understand-policy-based-access-control "Direct link to Understand policy-based access control")

[Role-based permissions](https://docs-docusaurus.kinsta.page/user-guides/aaa/access-control/permissions/.md) define global access by resource type, and policies refine access for specific resources.

For example:

* Global permissions can grant a user read access to Custom Dashboards, but a policy that denies access to a specific dashboard overrides this.
* Global permissions can grant a user read and manage access to datasets, but a policy for a specific dataset can restrict or extend this further.

When you configure a policy on a resource for the first time, the default general access reflects existing system behavior.

## Access modes[​](#access-modes "Direct link to Access modes")

Every access policy starts with a top-level mode selector — **Who can access this `<resource>`** — that controls how much of the editor is exposed:

* **Private** — only you can view and edit the resource. No other configuration is needed; this is the default for newly created resources.
* **Public** — anyone in the team with role-based access to this resource type can view and edit it. No other configuration is needed.
* **Advanced** — opens the full policy editor, with target group rules and general access. Use Advanced when you need to share a resource with specific groups or set broad team-wide access. Advanced mode also supports [Policy permissions](#policy-permissions), which let you delegate policy administration to other groups.

## Supported features[​](#supported-features "Direct link to Supported features")

Policies are currently available for the following Coralogix features:

* [Custom Dashboards](https://docs-docusaurus.kinsta.page/user-guides/custom-dashboards/tutorials/manage-dashboard-settings/.md#access-policies)

* [Team and Send-Your-Data API Keys](https://docs-docusaurus.kinsta.page/user-guides/account-management/api-keys/api-keys/.md#access-policies-for-api-keys)

* [Datasets](https://docs-docusaurus.kinsta.page/user-guides/data-layer/dataset-management/access-control/.md)

* [Explore](https://docs-docusaurus.kinsta.page/user-guides/monitoring-and-insights/explore-screen/create-and-manage-saved-views/.md)

## What you need to get started[​](#what-you-need-to-get-started "Direct link to What you need to get started")

To create or edit a policy for a resource, you must first have all required [permissions](#permissions), including role-based permissions that grant you eligibility to the resource type.

## Create a policy[​](#create-a-policy "Direct link to Create a policy")

<!--$?-->

<!--/$-->

The screenshot below shows the **Access Policy** panel in **Advanced** mode on an Explore saved view, with two target-group rules (`Admins` → **Manage**, `Analysts` → with the access-level dropdown open) and **General access** set to everyone in the team.

[![Access Policy editor in Advanced mode with two target-group rules and a General access setting](/assets/images/access-policy-advanced-404edb758eccec25ce2b410aac6b1554.webp)](https://docs-docusaurus.kinsta.page/assets/images/access-policy-advanced-404edb758eccec25ce2b410aac6b1554.webp)

## Policy permissions[​](#policy-permissions "Direct link to Policy permissions")

By default, only the policy creator can view or edit a policy's configuration. **Policy permissions** let you delegate that administration to other groups.

Note

Policy permissions are available only for certain resource types, such as Custom Dashboards.

To delegate this access, turn on the **Policy permissions** toggle in the top-right of the **Access Policy** panel. This adds a **Policy** access level to each target group rule and to the **General access** row, alongside the resource access level. The resource access level is labeled with the resource type as a prefix — for dashboards, **Dashboard: Manage** or **Dashboard: Read**. For the access level labels used by other resource types, see the documentation for that resource: [Custom Dashboards](https://docs-docusaurus.kinsta.page/user-guides/custom-dashboards/tutorials/manage-dashboard-settings/.md#access-policies), [API Keys](https://docs-docusaurus.kinsta.page/user-guides/account-management/api-keys/api-keys/.md#access-policies-for-api-keys), [Datasets](https://docs-docusaurus.kinsta.page/user-guides/data-layer/dataset-management/access-control/.md), and [Explore](https://docs-docusaurus.kinsta.page/user-guides/monitoring-and-insights/explore-screen/create-and-manage-saved-views/.md).

The **Policy** access level has three options:

* **Edit** — the group can view and change the policy, including adding, editing, and removing rules. This shares policy ownership with them.
* **View** — the group can view the policy configuration but can't save any changes to it.
* **No Access** — the group can neither view nor change the policy. This is the behavior when Policy permissions is off.

Note

For **Custom Dashboards**, read-only viewers (**Dashboard: Read**) can also be restricted to changing only the time range — see [Read-only dashboards](https://docs-docusaurus.kinsta.page/user-guides/custom-dashboards/tutorials/manage-dashboard-settings/.md#read-only-dashboards).

To restore the default configuration, select **Reset** (this removes all custom rules and returns the policy to its default state).

## Restricted group behavior[​](#restricted-group-behavior "Direct link to Restricted group behavior")

If the policy creator belongs to one or more [restricted groups](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/assign-user-roles-and-scopes-via-groups/.md), the system:

1. Converts the general access setting into per-restricted-group rules.
2. Sets general access to the restricted-group default (typically no access).

This makes content created by restricted-group members private-first by default.

## Configuration examples[​](#configuration-examples "Direct link to Configuration examples")

Level names in the steps that follow — **Read**, **Manage**, **No Access** — match the saved-views UI. The names differ by resource type (for example, datasets expose `readData`, `overwriteData`, `appendData`, `readAccessPolicy`, and `updateAccessPolicy`). The configuration pattern is the same in every case.

### Only me (Private)[​](#only-me-private "Direct link to Only me (Private)")

* **Goal**: No one else can view, manage, or take any other action.
* **Steps**:
  <!-- -->
  1. Set the mode to **Private**.
* **Result**: Only the policy owner has access.

### Team-only[​](#team-only "Direct link to Team-only")

* **Goal**: Only the `App A Devs` group can read (and optionally manage).

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **No Access**.
  3. In **Apply to target groups**, add a rule: target `App A Devs` → **Read** (or **Manage** if needed). Select **Apply**.

* **Result**: Users in `App A Devs` can read or manage; others are denied.

### Everyone, except group X[​](#everyone-except-group-x "Direct link to Everyone, except group X")

* **Goal**: Broad read access for all, except block the `London` group.

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **Read**.
  3. In **Apply to target groups**, add a rule: target `London` → **No Access**. Select **Apply**.

* **Result**: All users can read, except the `London` group.

### Read-only for all; Product-Managers can manage[​](#read-only-for-all-product-managers-can-manage "Direct link to Read-only for all; Product-Managers can manage")

* **Goal**: Everyone can read; `Product-Managers` can also manage.

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **Read**.
  3. In **Apply to target groups**, add a rule: target `Product-Managers` → **Manage**. Select **Apply**.

* **Result**: All users can read; `Product-Managers` can manage.

Note

For **Custom Dashboards**, you can further restrict read-only viewers to changing only the time range by turning on **Allow only time filters** on the rule. See [Read-only dashboards](https://docs-docusaurus.kinsta.page/user-guides/custom-dashboards/tutorials/manage-dashboard-settings/.md#read-only-dashboards).

### Sensitive dashboard visible only to SOC-Analysts[​](#sensitive-dashboard-visible-only-to-soc-analysts "Direct link to Sensitive dashboard visible only to SOC-Analysts")

* **Goal**: Keep it private to `SOC-Analysts`.

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **No Access**.
  3. In **Apply to target groups**, add a rule: target `SOC-Analysts` → **Read** (and **Manage** if needed). Select **Apply**.

* **Result**: Only `SOC-Analysts` have access.

### Allow everyone to read; Developers can manage[​](#allow-everyone-to-read-developers-can-manage "Direct link to Allow everyone to read; Developers can manage")

* **Goal**: Broad visibility, controlled changes.

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **Read**.
  3. In **Apply to target groups**, add a rule: target `Developers` → **Manage**. Select **Apply**.

* **Result**: All users can read; `Developers` can manage.

### Read-only dashboard with policy managed by an admin group[​](#read-only-dashboard-with-policy-managed-by-an-admin-group "Direct link to Read-only dashboard with policy managed by an admin group")

* **Goal**: A dashboard that a `Viewers` group can only read, while a `Dashboard-Admins` group can administer the policy itself.

* **Steps**:

  <!-- -->

  1. Set the mode to **Advanced**.
  2. Set **General access** to **No Access**.
  3. In **Apply to target groups**, add a rule: target `Viewers` → **Dashboard: Read**. Optionally turn on **Allow only time filters** to restrict them to changing the time range. Select **Apply**.
  4. Turn on the **Policy permissions** toggle.
  5. On the `Dashboard-Admins` rule (add one if needed), set the **Policy** access level to **Edit**.

* **Result**: `Viewers` can read the dashboard only; `Dashboard-Admins` can manage who has access without being able to edit the dashboard's contents.

## Permissions[​](#permissions "Direct link to Permissions")

To create or edit a policy for a resource, the following requirements must be met cumulatively.

### Global resource permissions[​](#global-resource-permissions "Direct link to Global resource permissions")

You must have global permissions that grant you visibility and management of the resource itself: `<resource_type>:Read` and `<resource_type>:Manage`.

### Policy owner permissions[​](#policy-owner-permissions "Direct link to Policy owner permissions")

As a policy creator, you automatically get permissions to view and update a resource's policy: `<resource_type>:ReadAccessPolicy` and `<resource_type>:UpdateAccessPolicy`.

As long as your policy is active, users with `access-policies:UpdateAll` and `access-policies:ReadAll` can override resource-specific policy permissions and disable your policy, effectively becoming the new policy owners.

Note

The resource's creator does not need to be the policy owner. One user can create a resource, and another user can create and own its policy.

### Target group permissions[​](#target-group-permissions "Direct link to Target group permissions")

To select and view target groups when building a policy, you need the following:

* `team-groups:ReadSummary`
* `team-groups:ReadConfig`

## Overriding access policies[​](#overriding-access-policies "Direct link to Overriding access policies")

Where appropriate, grant wide policy maintenance permissions so designated users can find and fix stale policies:

* `access-policies:ReadAll`
* `access-policies:UpdateAll`

These powerful permissions are not included in any out-of-the-box system roles.

## What happened to Scopes?[​](#what-happened-to-scopes "Direct link to What happened to Scopes?")

[Scopes](https://docs-docusaurus.kinsta.page/user-guides/account-management/user-management/scopes/.md) are a legacy access mechanism still used by some resource types (for example, default `/logs` and `/spans` datasets). They continue to work alongside policies in the legacy API.

For legacy scopes, membership is also additive — the user's visible data is the union of all group scopes they belong to.

## FAQs[​](#faqs "Direct link to FAQs")

### Q: I can't see the Access policy section. Why?[​](#q-i-cant-see-the-access-policy-section-why "Direct link to Q: I can't see the Access policy section. Why?")

You don't have permission to create or edit policies for this resource.

Ask your admin to check your `<resource_type>:ReadAccessPolicy` and `<resource_type>:UpdateAccessPolicy` permissions for this resource type.

### Q: I can't see groups when adding a rule. Why?[​](#q-i-cant-see-groups-when-adding-a-rule-why "Direct link to Q: I can't see groups when adding a rule. Why?")

You may be missing the `team-groups:ReadSummary` permission.

Ask your admin to enable it.

### Q: I can see some groups, but not all of them. Why?[​](#q-i-can-see-some-groups-but-not-all-of-them-why "Direct link to Q: I can see some groups, but not all of them. Why?")

Even if you have `team-groups:ReadSummary`, visibility still depends on the group type.

You can see:

* Open groups
* Private or restricted groups you are a member of

You can't see:

* Private or restricted groups you are not part of

### Q: I lost access to a policy I created. How can that happen?[​](#q-i-lost-access-to-a-policy-i-created-how-can-that-happen "Direct link to Q: I lost access to a policy I created. How can that happen?")

Common reasons:

* You lost the global permissions required to view or manage policies.
* An admin or user with `access-policies:ReadAll` and `access-policies:UpdateAll` permissions replaced or removed your policy.

### Q: I lost access to a resource. How can that happen?[​](#q-i-lost-access-to-a-resource-how-can-that-happen "Direct link to Q: I lost access to a resource. How can that happen?")

Possible causes:

* You were removed from a private/restricted group included in the policy.
* The group used by the policy was deleted.
* Another user with permissions updated the policy and changed who is allowed.