CEL Conditions & Access Patterns#

#Objective

This page covers how to grant users access to policy-tagged data using CEL (Common Expression Language) conditions. For an overview of policy tags, the gate chain, and how to bind tags to data, see Policy Tags Overview.

#Table of Contents

1. Granting Access with CEL Conditions
2. Best Practices

#Granting Access with CEL Conditions

Granting a user access to policy-tagged data is a two-part process:

1. Assign the policy tag value to the user via the Grant Access UI in Lakehouse Manager
2. Verify or edit the CEL condition on the user's role binding in the Identity Access Manager

#Using the Grant Access UI

The Grant Access UI provides a quick way to assign policy tag values to users:

1. Open the Grant Access menu.

   

2. Select the policy tag you want to assign and specify the access type: Read for read-only access, or Read and Write for both.

   

3. Assign the policy tag values (e.g., access_level: level 1) to the user or group.

   

4. Confirm and save the access settings.

#Writing CEL Conditions Manually

To correctly scope policy tag access, you must edit the CEL condition on the user's role binding in the Identity Access Manager.

The Grant Access UI generates a CEL condition like this:

Service == "adac" && (PolicyTags.sensitivity == "high")

This condition checks PolicyTags.sensitivity == "high" at every resource level. If the dataset doesn't have sensitivity: high (only the table does), the dataset check fails and the user is denied.

To fix this, edit the CEL condition to scope the policy tag check to specific resource levels using Resource:

Service == "adac" && (
  Resource == "dataset"
  || (PolicyTags.sensitivity == "high" && Resource == "table")
  || Resource == "attribute"
)

This condition means:

• At the dataset level: always pass (no tag check needed)
• At the table level: require sensitivity: high
• At the attribute level: always pass (no tag check needed)

To edit the CEL condition:

1. Open the Identity Access Manager and navigate to the user or group.
2. Find the ADAC role binding (the one with Service adac).
3. Click Edit on the condition.
4. Switch to the CEL editor and replace the generated condition with the Resource-scoped version.
5. Save.

#Common CEL Patterns

Below are ready-to-use CEL patterns for common scenarios. In each pattern, replace tag keys and values with your own.

1. Enforce tags at ALL levels (dataset, table, and attribute), recommended for full access control:

Service == "adac" && (
  (PolicyTags.access_level == "level 1" && Resource == "dataset")
  || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "table")
  || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "attribute")
)

This checks tags at every level. A user with level 1 + level 2 can access the dataset, tables tagged up to level 2, and attributes tagged up to level 2. Attributes tagged level 3 will be denied.

2. Enforce tags at table level only (dataset and attribute pass-through):

Service == "adac" && (
  Resource == "dataset"
  || (PolicyTags.sensitivity == "high" && Resource == "table")
  || Resource == "attribute"
)

3. Grant access to tables that do NOT have a specific tag:

Service == "adac" && (
  Resource == "dataset"
  || (!has(PolicyTags.sensitivity) && Resource == "table")
  || Resource == "attribute"
)

4. Enforce at dataset level only (all tables and attributes pass through):

Service == "adac" && (
  (PolicyTags.sensitivity == "high" && Resource == "dataset")
  || Resource == "table"
  || Resource == "attribute"
)

5. Enforce at dataset and table levels (attribute pass-through):

Service == "adac" && (
  (PolicyTags.department == "finance" && Resource == "dataset")
  || (PolicyTags.sensitivity == "high" && Resource == "table")
  || Resource == "attribute"
)

6. Enforce at attribute level only:

Service == "adac" && (
  Resource == "dataset"
  || Resource == "table"
  || (PolicyTags.sensitivity == "high" && Resource == "attribute")
)

7. Combine multiple tag values (user needs any of the listed values):

Service == "adac" && (
  Resource == "dataset"
  || (PolicyTags.sensitivity in ["high", "medium"] && Resource == "table")
  || Resource == "attribute"
)

#Best Practices

• Always tag at the dataset level first. Since the gate chain starts at the dataset, an untagged dataset with tagged tables creates a confusing setup. Set a baseline tag on the dataset.

• Use Resource-scoped CEL conditions. Never rely on the default CEL generated by the Grant Access UI for production access control. Always edit the CEL to include Resource scoping.

• Order CEL checks as dataset → table → attribute. This matches the gate chain evaluation order and makes conditions easier to read and debug.

• Keep tag structures simple. Use a single tag key (e.g., sensitivity) with a small number of values (e.g., public, internal, restricted). Avoid deeply nested tag combinations.

• Grant cumulative tags. Remember that users need tags for every level in the chain. If a user needs restricted table access, they also need whatever tag is on the parent dataset.

• Test with a dedicated user. Before rolling out access policies, create a test user and verify each level of the gate chain independently. See Testing Access Control.

• Audit CEL conditions regularly. As policy tags change, CEL conditions on role bindings may become stale. Review them when modifying tag bindings.

• Document your tag schema. Keep a record of which tag keys and values are in use, what they mean, and which resources they're bound to.

#Go further

If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.

Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated Discord channel.

If you need support with your OVHcloud services, create a request in our Help Centre.

Join our community of users.