For AI agents: the complete documentation index is available at https://docs.dataplatform.ovh.net/llms.txt, the full documentation bundle is available at https://docs.dataplatform.ovh.net/llms-full.txt, and this page is available as Markdown at https://docs.dataplatform.ovh.net/lakehouse-manager-policy-tags-groups-example.md.
  • 🇬🇧 English

    • Example: Team Access with Groups

    This walkthrough demonstrates how to use policy tags together with IAM groups and roles to manage data access for team members

    Objective

    This walkthrough demonstrates how to use policy tags together with IAM groups and roles to manage data access for team members. By assigning a CEL condition to a group's role binding, every user added to the group automatically inherits the correct access level.

    Table of Contents

    1. Scenario
    2. Step 1: Design the Tag Schema
    3. Step 2: Create and Bind Policy Tags
    4. Step 3: Create the IAM Group
    5. Step 4: Configure the CEL Condition on the Group
    6. Step 5: Add Users to the Group
    7. Step 6: Verify Access
    8. Extending the Setup

    Scenario

    Your company has a dataset called employee_data containing the following tables:

    TableDescriptionWho should access
    office_locationsOffice addresses, floor plansEveryone
    team_directoryEmployee names, titles, departmentsEveryone
    salary_detailsCompensation, bonuses, equityHR only
    performance_reviewsReview scores, manager notesManagement only

    The salary_details table has an attribute national_id that contains personally identifiable information (PII) and should only be accessible to senior HR staff.

    Goal: New team members (newcomers) should be able to access office_locations and team_directory, but not salary_details or performance_reviews. HR staff should access salary data but not see national_id unless they are senior HR.

    Step 1: Design the Tag Schema

    Create a policy tag key access_level with three values:

    ValuePurpose
    generalBaseline access. All employees
    hrHR-restricted data (salaries, benefits)
    managementManagement-restricted data (reviews, notes)

    Additionally, create a tag key pii with one value:

    ValuePurpose
    restrictedPersonally identifiable information, senior HR only

    Step 2: Create and Bind Policy Tags

    Create the policy tags access_level (with values general, hr, management) and pii (with value restricted).

    Then bind them to data:

    ResourceTag
    Dataset employee_dataaccess_level: general
    Table salary_detailsaccess_level: hr
    Table performance_reviewsaccess_level: management
    Attribute salary_details.national_idpii: restricted

    Tables office_locations and team_directory have no explicit tags. They inherit access_level: general from the dataset.

    flowchart TD
    DS["employee_data<br/><b>access_level: general</b>"]
    DS --> T1["office_locations<br/><i>inherits: general</i>"]
    DS --> T2["team_directory<br/><i>inherits: general</i>"]
    DS --> T3["salary_details<br/><b>access_level: hr</b>"]
    DS --> T4["performance_reviews<br/><b>access_level: management</b>"]
    T3 --> A1["national_id<br/><b>pii: restricted</b>"]
    T3 --> A2["other columns<br/><i>inherits: hr</i>"]

    style DS fill:#0089C0,color:#fff
    style T1 fill:#e8f4f8
    style T2 fill:#e8f4f8
    style T3 fill:#f0ad4e,color:#fff
    style T4 fill:#d9534f,color:#fff
    style A1 fill:#d9534f,color:#fff
    style A2 fill:#f0ad4e,color:#fff

    Step 3: Create the IAM Group

    In the Identity Access Manager, create three groups:

    GroupPurpose
    New JoinersNew team members, general access only
    HR TeamHR staff, access to salary data (excluding PII)
    Senior HRSenior HR, full access including PII

    For each group, assign the ADAC Reader role (or the appropriate role that includes Advanced Data Access Control read permissions).

    Info

    For step-by-step instructions on creating groups and assigning roles, see Groups.

    Step 4: Configure the CEL Condition on the Group

    For each group's ADAC role binding, set the CEL condition in the IAM. Remember: conditions must follow the gate chain order, dataset → table → attribute.

    New Joiners: access to general data only:

    Service == "adac" && (
  (PolicyTags.access_level == "general" && Resource == "dataset")
  || (PolicyTags.access_level == "general" && Resource == "table")
  || (PolicyTags.access_level == "general" && Resource == "attribute")
)

    This CEL enforces access_level: general at every level. New joiners can access office_locations and team_directory (which inherit general from the dataset) but not salary_details (hr) or performance_reviews (management).

    HR Team: access to general + hr data, but NOT PII attributes:

    Service == "adac" && (
  (PolicyTags.access_level == "general" && Resource == "dataset")
  || (PolicyTags.access_level in ["general", "hr"] && Resource == "table")
  || (PolicyTags.access_level in ["general", "hr"] && !has(PolicyTags.pii) && Resource == "attribute")
)

    This CEL:

    • Dataset level: requires access_level: general: passes for employee_data
    • Table level: allows general or hr: passes for all tables except performance_reviews (management)
    • Attribute level: allows general or hr BUT also requires the pii tag to not exist: denies national_id (which has pii: restricted)
    Info

    The !has(PolicyTags.pii) check ensures that any attribute tagged with the pii key is denied, regardless of its value. This is useful for blanket PII protection.

    Senior HR: full access to general + hr data including PII:

    Service == "adac" && (
  (PolicyTags.access_level == "general" && Resource == "dataset")
  || (PolicyTags.access_level in ["general", "hr"] && Resource == "table")
  || (PolicyTags.access_level in ["general", "hr"] && Resource == "attribute")
)

    This CEL is the same as HR Team but without the !has(PolicyTags.pii) restriction. Senior HR can access national_id.

    Warning

    To edit these CEL conditions, navigate to the group's role binding in the IAM and switch to the CEL editor. See Writing CEL Conditions Manually for instructions.

    Step 5: Add Users to the Group

    When a new team member joins:

    1. Create their user account in the IAM.
    2. Assign them the required base roles:
      • Organization Level: Organization Viewer
      • Project Level: AM Admin (or the appropriate role for their work)
    3. Add them to the New Joiners group.

    That's it. The group's CEL condition automatically grants them access to general-tagged data. No need to configure individual CEL conditions.

    When they move to the HR team:

    1. Remove them from New Joiners.
    2. Add them to HR Team.

    Their access updates immediately: they can now see salary_details (except national_id) in addition to the general tables.

    Step 6: Verify Access

    Use the Explorer to verify access for a user in each group:

    As a New Joiner:

    QueryExpected Result
    SELECT * FROM office_locationsSuccess, inherits general
    SELECT * FROM team_directorySuccess, inherits general
    SELECT * FROM salary_detailsError, table requires hr
    SELECT * FROM performance_reviewsError, table requires management

    As HR Team member:

    QueryExpected Result
    SELECT * FROM office_locationsSuccess
    SELECT * FROM salary_detailsError, SELECT * includes national_id (PII)
    SELECT name, salary, bonus FROM salary_detailsSuccess. No PII columns
    SELECT national_id FROM salary_detailsError, national_id has pii: restricted
    SELECT * FROM performance_reviewsError, table requires management

    As Senior HR:

    QueryExpected Result
    SELECT * FROM salary_detailsSuccess, including national_id
    SELECT * FROM performance_reviewsError, still requires management

    Extending the Setup

    Adding a Management group

    To give managers access to performance_reviews, create a Management group with this CEL:

    Service == "adac" && (
  (PolicyTags.access_level == "general" && Resource == "dataset")
  || (PolicyTags.access_level in ["general", "management"] && Resource == "table")
  || (PolicyTags.access_level in ["general", "management"] && Resource == "attribute")
)

    Users in multiple groups

    A user can belong to multiple groups. If someone is in both HR Team and Management, they get the union of both groups' permissions. They can access both salary_details and performance_reviews.

    Info

    When a user belongs to multiple groups, each group's role binding is evaluated independently. If any role binding's CEL condition passes, the user is granted access. This makes multi-group setups additive.

    Service accounts

    Service accounts can also be added to groups. If you have a reporting pipeline that needs to read general data, add its service account to the New Joiners group rather than configuring individual CEL conditions.

    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.