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, MSPs, 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

Role-based permissions 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 read access to a specific dashboard overrides this.
• Global permissions can grant a user read and write access to datasets, but a policy for a specific dataset can extend this access to read, overwrite, and append.

When you enable a policy on a resource for the first time, a default access policy is created based on the resource type, preserving 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, first and foremost, role-based permissions that grant you eligibility to the resource type.

Create a policy

Follow these steps from the resource's Access policy section.

Step 1. Set general access

General access sets the default access level for everyone in your team. Select an access level from the dropdown — available options differ by resource type.

Step 2. 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 the group using the dropdown.
3. To add another rule, select + Add.
4. To remove a rule, select the remove icon next to it.

Step 3. Configure policy access (optional)

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

Step 4. 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 policy’s default into per‑restricted‑group rules.
2. Sets the policy default to the restricted‑group default (typically deny‑all).

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. Enable policy
  2. Default rule: None
  3. No exceptions
• Result: Only the policy owner has access (and safety net, high privilege users).

Team‑only

• Goal: Only the App A Devs group can view (and optionally manage).
• Steps:
  1. Enable policy
  2. Default rule: None
  3. Add exception: target App A Devs → allow Read (and Manage if needed)
• Result: Users in App A Devs can view (and manage if granted); others are denied.

Everyone, except group X

• Goal: Broad read access for all, except block the London group.
• Steps:
  1. Enable policy
  2. Default rule: Enabled → Read
  3. Add exception: target London → allowed actions None
• Result: All users can read, except the London group.

Read‑only for all; Product‑Managers can edit

• Goal: Everyone can read; Product‑Managers can also manage.
• Steps:
  1. Enable policy
  2. Default rule: Enabled → Read
  3. Add exception: target Product‑Managers → allow Read and Manage
  4. Result: All users can read; Product‑Managers can manage.

Sensitive dashboard visible only to SOC‑Analysts

• Goal: Keep it private to SOC‑Analysts.
• Steps:
  1. Enable policy
  2. Default rule: None
  3. Add exception: target SOC‑Analysts → allow Read, Manage
• Result: Only SOC‑Analysts have access.

Allow everyone to read; Developers can edit

• Goal: Broad visibility, controlled edits.
• Steps:
  1. Enable policy
  2. Default rule: Enabled → Read
  3. Add exception: target Developers → allow Read and Manage
• Result: All users can read; Developers can manage.

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 aaa/access-policies:UpdateConfig and aaa/access-policies:ReadConfig can override resource-specific policy permissions and disable your policy, effectively becoming the new policy owners.

Policy editor permissions

In addition to controlling who can access the resource, policy owners can define who can view or manage the policy itself, thereby becoming policy editors.

• Actions for policy administration, such as ReadPolicy and ManagePolicy, are available in the Allowed actions dropdowns (for both default and exception rules).
• These actions determine who can see or modify the policy configuration.
• The Allowed actions dropdown includes both resource actions and policy administration actions.
• If no policy administration rule is defined, only the policy creator can view and update the policy.
• Granting ManagePolicy to other users or groups 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, both for the UI and API. Where scopes exist, they appear in the Policy Access editor as existing rules, each with a rule ID for reference.

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 policy configuration options. 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 in the policy editor. 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:ReadAlland 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.