Access Control for System Datasets

System datasets support fine-grained access control that combines permissions and policies. This lets you manage dataset visibility and edit rights with precision.

Understanding access layers

Permissions define global access per resource type, whereas policies refine access at the resource level. Thus, global permissions may define that a user has read access to datasets generally, but a policy denying read access to a particular dataset may override this. Or, global permissions may define that a user has read and write access to datasets generally, but a specific policy may extend these permissions, granting read, overwrite, and append access to a particular dataset.

When you enable a policy on a dataset for the first time, a default access policy is created based on the dataset type and ownership. These defaults preserve existing behavior for system datasets.

What you need

To create or edit a policy for a dataset, you must have all of the necessary permissions.

Creating an access policy for a dataset

In the Dataset Management page, click and choose Edit dataset. The edit drawer opens with metadata, storage, and access control fields.

Step 1. Enable access policy

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

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. Restrict access to specific subsets of a dataset

Attach a DPXL expression to scope what data is accessible within an exception rule. This lets you restrict access to specific subsets of the dataset.

Step 4. Save your changes

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

System dataset defaults

System datasets are predefined by Coralogix and automatically marked as Restricted. Each has a default access policy to prevent accidental exposure of sensitive operational data.

These datasets are readable only by owners and users who are explicitly added through policy rules.

Example: Restrict a dataset to an admin team

1. Open the alerts.history dataset in Dataset Management.
2. Set the default rule to None.
3. Add a rule for the platform-admin group with readData.
4. Add a DPXL query: <v1> region_id:string.in('us-east-1', 'us-west-2')

Policy result: The alerts.history dataset is not accessible, with the exception of platform administrators who have read access to data from regions us-east-1 and us-west-2.

Permissions

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

Global resource permissions

You must have permissions that grant you visibility and management of datasets, found in the data engine preset.

Dataset type	Action	Description	Permission
System	View system datasets configuration	Access the dataspace System screen and view system datasets configuration and status	SYSTEM-DATASETS:READCONFIG
System	Manage system datasets	Enable or disable write options for specific system datasets	SYSTEM-DATASETS:MANAGE

Resource actions

To read, append, or overwrite system datasets, you must have the following permissions. Resource action permissions are available in the Allowed actions dropdowns (for both default and exception rules).

Dataset type	Action	Description	Permission
System	Read data from system datasets	Read data from any system dataset	SYSTEM-DATASETS:READDATA
System	Add new data to system datasets	Append new data to an existing system dataset	SYSTEM-DATASETS:APPENDDATA
System	Replace system dataset content	Overwrite data in a specific system dataset	SYSTEM-DATASETS:OVERWRITEDATA

Policy owner permissions

As a policy creator, you automatically get permissions to view and update a resource’s policy.  

Dataset type	Action	Description	Permission
System	Read system dataset access policy	Open a system dataset modal and view its access rule and exception rule	SYSTEM-DATASETS:READACCESSPOLICY
System	Update system dataset access policy	Open a system dataset modal and manage its access rule and exception rule	SYSTEM-DATASETS: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 dataset, policy owners can define who can view or manage the policy itself, thereby becoming policy editors.

• Actions for policy administration, such as READACCESSPOLICY and UPDATEACCESSPOLICY, 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 UPDATEACCESSPOLICY 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 permissions:

Action	Description	Required permission
View target group summary	Select and view target groups based on summary data when building a policy.	team-groups:ReadSummary
View target group config	Select and view full target group configuration when building a policy.	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.

Learn more

• Dataspaces
• Datasets
• Dataset Management