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

• 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

Understand policy-based access control

flowchart TD
    A([User requests resource access]) --> B{"Role-based permission<br>for this resource type?"}
    B -- No --> Z(["Access denied"])
    B -- Yes --> C{"Resource has<br>an access policy?"}
    C -- No --> D(["Access granted<br>at global level"])
    C -- Yes --> E{"User in a<br>target group rule?"}
    E -- Yes --> F["Apply group rule<br>access level"]
    E -- No --> G["Apply general<br>access level"]
    F --> H{"Access level?"}
    G --> H
    H -- "No access" --> Z
    H -- "View or Edit" --> I(["Access granted"])

Role-based permissions define global access by resource type, and policies refine access for specific resources.

For example:

• Global permissions can grant a user view access to Custom Dashboards, but a policy that denies access to a specific dashboard overrides this.
• Global permissions can grant a user view and edit 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.

Supported features

Policies are currently available for the following Coralogix features:

• Custom Dashboards

• Team and Send-Your-Data API Keys

• System Datasets

What you need to get started

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

Create a policy

Follow these steps from the resource settings panel.

Step 1. Open the resource settings

Navigate to the resource (for example, a Custom Dashboard). Open its settings from the settings icon or more actions menu, then scroll to the Access policy section.

Step 2. Set general access

General access controls the default access level for everyone in your team. Select an access level from the dropdown — for example, Dashboard: No access or Dashboard: View. Available options differ by resource type.

Step 3. Add target group rules (optional)

Override the default for specific groups:

1. In the Add groups to define a rule field, search for and select one or more groups.
2. Set the access level for those groups using the action dropdown.
3. To add another rule, select + Add.
4. To remove a rule, select the remove icon next to it.

Step 4. Configure policy access (optional)

To control who can view or edit the policy configuration itself, toggle on Show advanced. This reveals a Policy column next to each rule, including the general access row. Set the policy access level for each row as needed.

Step 5. Save your changes

Select Save to activate the policy. To restore the default policy configuration, select Reset.

Restricted group behavior

If the policy creator belongs to one or more restricted groups, 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

Only me (Private)

• Goal: No one else can view, manage, or take any other action.
• Steps:
  1. Set General access to No access.
  2. Add no group rules.
• Result: Only the policy owner has access.

Team-only

• Goal: Only the App A Devs group can view (and optionally edit).
• Steps:
  1. Set General access to No access.
  2. Add a rule: target App A Devs → View (or Edit if needed).
• Result: Users in App A Devs can view or edit; others are denied.

Everyone, except group X

• Goal: Broad view access for all, except block the London group.
• Steps:
  1. Set General access to View.
  2. Add a rule: target London → No access.
• Result: All users can view, except the London group.

View-only for all; Product-Managers can edit

• Goal: Everyone can view; Product-Managers can also edit.
• Steps:
  1. Set General access to View.
  2. Add a rule: target Product-Managers → Edit.
• Result: All users can view; Product-Managers can edit.

Sensitive dashboard visible only to SOC-Analysts

• Goal: Keep it private to SOC-Analysts.
• Steps:
  1. Set General access to No access.
  2. Add a rule: target SOC-Analysts → View (and Edit if needed).
• Result: Only SOC-Analysts have access.

Allow everyone to view; Developers can edit

• Goal: Broad visibility, controlled edits.
• Steps:
  1. Set General access to View.
  2. Add a rule: target Developers → Edit.
• Result: All users can view; Developers can edit.

Permissions

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

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

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.

Policy editor permissions

Policy owners can control who can view or manage the policy configuration itself. Toggle on Show advanced in the Access policy section to reveal the Policy column, where you can set policy access for each rule row.

• The Policy column is available for both the general access row and each target group rule.
• If no policy access is set, only the policy creator can view and update the policy.
• Granting policy edit access to a group shares policy ownership with them, so they can update, delete, or add new rules.

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

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?

Scopes 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

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?

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?

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?

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?

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.