---
title: "CEL Conditions & Access Patterns"
description: "This page covers how to grant users access to policy-tagged data using CEL (Common Expression Language) conditions"
url: https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-cel-conditions
lang: pt
lastUpdated: 2026-09-14
---
> For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/pt/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/pt/llms-full.txt.
# 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](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/lakehouse-manager-policy-tags.md).
## Table of Contents
1. [Granting Access with CEL Conditions](#granting-access-with-cel-conditions)
2. [Best Practices](#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.
:::warning
**Important limitation**: The Grant Access UI generates a CEL condition without Resource-level scoping. This means the condition is evaluated at **every level** of the gate chain (dataset, table, attribute). If the policy tag is only applied at the table level, the dataset-level check will fail and the user will be denied access. **You must manually edit the CEL condition** in the IAM to add Resource scoping. See [Writing CEL Conditions Manually](#writing-cel-conditions-manually) below.
:::
:::info
**Note**: Users without **Advanced Data Access Control** permissions cannot read or write to any dataset, table, or attribute by default. This can be verified in the [IAM settings](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/landing-page-iam.md) for the user.
:::
### 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](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/iam-roles-conditions.md#new-cel-conditions).
The Grant Access UI generates a CEL condition like this:
```text
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`:
```text
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](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/iam-roles-conditions.md#new-cel-conditions) 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.
:::info
Note the comment `// Permissions are managed in Lakehouse Manager. Do not update here!` on line 1. This is auto-generated by the Grant Access UI. You can safely replace the CEL content below it with your Resource-scoped condition.
:::
### Common CEL Patterns
Below are ready-to-use CEL patterns for common scenarios. In each pattern, replace tag keys and values with your own.
:::warning
**Critical:** Any resource level with a plain pass-through (e.g., `|| Resource == "dataset"`) has **no tag enforcement** at that level. Only use pass-throughs for levels where you intentionally want to skip tag checks. All patterns below list conditions in gate chain order: dataset → table → attribute.
:::
**1. Enforce tags at ALL levels (dataset, table, and attribute), recommended for full access control:**
```text
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):**
```text
Service == "adac" && (
Resource == "dataset"
|| (PolicyTags.sensitivity == "high" && Resource == "table")
|| Resource == "attribute"
)
```
:::info
Use this when you only tag tables and don't need dataset-level or attribute-level restrictions. Note: attribute-level tags are **not enforced** with this pattern.
:::
**3. Grant access to tables that do NOT have a specific tag:**
```text
Service == "adac" && (
Resource == "dataset"
|| (!has(PolicyTags.sensitivity) && Resource == "table")
|| Resource == "attribute"
)
```
**4. Enforce at dataset level only (all tables and attributes pass through):**
```text
Service == "adac" && (
(PolicyTags.sensitivity == "high" && Resource == "dataset")
|| Resource == "table"
|| Resource == "attribute"
)
```
:::info
Use this when you only need to gate access at the dataset level. All tables and attributes within the dataset are accessible if the dataset gate passes.
:::
**5. Enforce at dataset and table levels (attribute pass-through):**
```text
Service == "adac" && (
(PolicyTags.department == "finance" && Resource == "dataset")
|| (PolicyTags.sensitivity == "high" && Resource == "table")
|| Resource == "attribute"
)
```
:::info
Attribute-level tags are **not enforced** with this pattern.
:::
**6. Enforce at attribute level only:**
```text
Service == "adac" && (
Resource == "dataset"
|| Resource == "table"
|| (PolicyTags.sensitivity == "high" && Resource == "attribute")
)
```
**7. Combine multiple tag values (user needs any of the listed values):**
```text
Service == "adac" && (
Resource == "dataset"
|| (PolicyTags.sensitivity in ["high", "medium"] && Resource == "table")
|| Resource == "attribute"
)
```
:::info
For more information on CEL syntax, operators, and the visual condition builder, see [Roles and Conditions, CEL Conditions](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/iam-roles-conditions.md#new-cel-conditions).
:::
## 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](https://docs.ovhcloud.com/pt/guides/public-cloud/data-platform/lakehouse-manager-policy-tags-testing.md).
- **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](https://www.ovhcloud.com/pt/professional-services/) 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](https://discord.gg/ovhcloud).
If you need support with your OVHcloud services, create a request in our [Help Centre](https://help.ovhcloud.com/csm?id=csm_get_help).
Join our [community of users](https://community.ovhcloud.com/).