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, for dashboards and folders

• 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 on the resource’s policy page.

Step 1. Enable access policy

Enable policy creation by toggling the switch. This turns the policy on for the specific resource.

Step 2. Define allowed and default actions

The default rule sets the baseline for all users who have the relevant permissions for this resource type. You can override this baseline later for specific target groups using exception rules.

Allowed actions

First, select None or Enabled:

• None: No one can take actions on the resource except the policy creator.
• Enabled: Choose the baseline actions to allow for others (for example, readData). Available actions differ by resource type. Selecting all permitted actions effectively mirrors the global permissions behavior.

Default actions

Choose the allowed actions for both the resource and the policy itself:

• Resource actions: Control what users can do with the resource (e.g, read, write,readData, overwriteData, and appendData).
• Policy actions (ReadAccessPolicy and ManageAccessPolicy): Control who can view or edit the policy configuration itself.

Choose Select All to allow all actions.

Default actions apply to users who are not part of any exception rule.

Add exception rules

Use exception rules to adjust access for specific groups relative to the default.

For each rule, select the target group and allowed actions. Set to None for no allowed actions or Enabled to allow one or more actions.

Add multiple rules as needed.

Examples:

• If the default is Enabled → Read, you can add an exception to grant a group overwriteData.
• If the default is None, you can add an exception to grant a group readData and/or overwriteData.
• To block a specific group when the default allows access, add an exception for that group with the allowed actions set to None.

Step 3. Save your changes

Select Save to activate the policy. The resource’s access control behavior now follows the configured rules.

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.

Resource tree structure handling

Some resources, such as dashboard folders, are organized in a tree structure with parents and children.

• When you set a policy on a parent resource (for example, a dashboard folder), that policy applies to all child resources by default (for example, dashboards in the folder).
• If the feature supports overrides, you can set a different policy on a child resource. In that case, the child resource follows its own policy instead of inheriting the parent policy.

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.

Sensitive folder

Apply policies at the folder level in Custom Dashboards to manage multiple dashboards simultaneously.

Behavior:

• Folder rules cascade to dashboards, unless the dashboard has its own access policy.
• Folder restrictions take precedence over child dashboard rules.

Example:

A folder restricted to the “Security” group hides all dashboards inside; a dashboard with its own explicit access policy will override the inherited rule.

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.

Q: If a folder is restricted to a group I’m not in, will I lose access to a dashboard I created inside it?

No.

A dashboard with its own access policy always overrides the folder-level access policy.

Your dashboard remains accessible to you because the creator rule guarantees your access.