PBAC Policies

Note

This feature is in Alpha and is limited to early‑access customers. Broader availability is planned for a future release.

What is PBAC?

Policy‑based access control (PBAC) adds entity‑level policies on top of your existing role‑based access control (RBAC). Instead of every user engaging with every resource of a given type, PBAC lets you decide who can view or manage a specific resource based on defined policies. This reduces noise, protects sensitive work, and enables private or siloed workflows.

Use PBAC to:

Secure resource‑level access for dashboards, datasets, alerts, team API keys, and more.
Streamline workflows by showing users only what’s relevant.
Reduce risk by limiting exposure to sensitive content using group‑based rules.
Enable secure collaboration across teams, MSPs, or customers.

Core concepts

Entity type

A core component in Coralogix, such as dashboards, alerts, datasets, or API keys.

Entity

A specific instance within an entity type, such as a personalized dashboard or a particular team API key. Each entity has its own resource ID. PBAC lets you create per‑entity policies.

Actions

Operations that can be allowed on an entity type or entity. Typical actions include read and manage. Actions map to the permissions for that entity type.

Groups

Logical collections of Coralogix users. Users receive RBAC permissions and entity‑level policies through their group memberships. If a user belongs to multiple groups, they inherit the union of permissions and policies from those groups; matching group rules are OR‑combined.

Policy

A set of one or more rules that grants specific actions to target groups (or users) for a single entity. A policy defines the entity’s default access and any exceptions.

Example: By default, Company X lets all users read and manage Custom Dashboards. A PBAC policy can replace this with tailored rules for specific groups or users.

How PBAC works

PBAC augments RBAC with per‑entity policies. Access is determined by two layers that work together:

RBAC defines global permissions per entity type (for example, dashboards, datasets, API keys). Users inherit role‑based permissions through their groups.
PBAC refines access at the entity level. It applies per‑entity overrides to the RBAC baseline using policies defined by the entity’s creator.

The final decision is an intersection: the user must be eligible under RBAC for the entity type and allowed by the PBAC policy for the specific entity. The entity’s creator always has full access.

Evaluation order

When an entity has a policy, evaluation occurs in this order:

RBAC gate (by entity type). Group‑based RBAC permissions grant or deny eligibility for an entity type (for example, Custom Dashboards).
PBAC refinement (by entity). If RBAC grants eligibility for the entity type, the entity’s policy is evaluated:
User‑specific rules are checked first.
Group rules are checked next; all applicable group rules are OR‑combined.
If no rule matches, the entity’s default rule applies.

Permissions

To create or edit a policy for an entity, the following are cumulatively required.

Policy‑creation permissions

You must have permissions to view and update the entity’s policy: <ENTITY_TYPE>:ReadAccessPolicy and <ENTITY_TYPE>:UpdateAccessPolicy.

Note: Admins with aaa/access-policies:UpdateConfig and aaa/access-policies:ReadConfig can override entity‑specific policy permissions.

RBAC permissions

You must either be the entity’s creator or belong to a group included in the entity type’s RBAC access (for example, investigations:ReadAll).

Target group permissions

To select and view target groups when building a policy, you need one of:

team-groups:ReadSummary
team-groups:ReadConfig

Create a policy

Follow these steps on the entity’s policy page.

1. Turn on policy (empty state)

Enable policy creation by toggling the switch. This turns on PBAC for the entity (Access mode becomes Restricted).

2. Set the default rule (baseline)

The default rule sets the baseline for all users who are RBAC‑eligible for the entity type. You can override this baseline for specific groups using exception rules.

Select None or Enabled:

None: No one can take actions on the entity except its creator.
Enabled: Choose the baseline actions to allow (for example, read). Available actions differ by entity type. Selecting all permitted actions effectively mirrors the RBAC behavior.

3. Add exception rules

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

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

Select a target group and specify the allowed actions for that group. Add multiple rules as needed.

Ownership semantics (creator rule)

As the entity’s creator, you always have full access. When you create a resource and define a policy, the system injects an owner rule at evaluation time so you can always read and update that resource’s access policy without adding yourself explicitly.

Restricted group behavior

If the creator belongs to one or more restricted groups, the system:

Converts the policy’s default into per‑restricted‑group rules.
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

Goal: No one else can view or manage.
Steps:
Enable policy
Default rule: None
No exceptions
Result: Only the creator has access (via the injected creator rule).

Team‑only

Goal: Only the Developers group can view (and optionally manage).
Steps:
Enable policy
Default rule: None
Add exception: target Developers → allow read (and manage if needed)
Result: Users in Developers can view (and manage if granted); others are denied.

Everyone except X

Goal: Broad read access for all, except block the London group.
Steps:
Enable policy
Default rule: Enabled → Read
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:
Enable policy
Default rule: Enabled → Read
Add exception: target Product‑Managers → allow manage
Result: All users can read; Product‑Managers can manage.

Sensitive alert visible only to SOC‑Analysts

Goal: Keep it private to SOC‑Analysts.
Steps:
Enable policy
Default rule: None
Add exception: target SOC‑Analysts → allow read, manage
Result: Only SOC‑Analysts (plus the creator) have access.

Allow everyone to read; Developers can edit

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

Safety net (avoid forgotten resources)

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

access-policies:ReadAll
access-policies:UpdateAll

What happened to Scopes?

Scopes are a legacy PBAC mechanism still used by some entity types (for example, default /logs and /spans datasets). They continue to work alongside PBAC, both for the UI and API. Where scopes exist, they appear in the PBAC 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.

Previous Permissions

Next Scopes