Policies Guide

Introduction

DataHub provides the ability to declare fine-grained access control Policies via the UI & GraphQL API. Access policies in DataHub define who can do what to which resources. A few policies in plain English include

• Dataset Owners should be allowed to edit documentation, but not Tags.
• Jenny, our Data Steward, should be allowed to edit Tags for any Dashboard, but no other metadata.
• James, a Data Analyst, should be allowed to edit the Links for a specific Data Pipeline he is a downstream consumer of.
• The Data Platform team should be allowed to manage users & groups, view platform analytics, & manage policies themselves.

In this document, we'll take a deeper look at DataHub Policies & how to use them effectively.

What is a Policy?

There are 2 types of Policy within DataHub:

1. Platform Policies
2. Metadata Policies

We'll briefly describe each.

Platform Policies

Platform policies determine who has platform-level privileges on DataHub. These privileges include

• Managing Users & Groups
• Viewing the DataHub Analytics Page
• Managing Policies themselves

Platform policies can be broken down into 2 parts:

1. Actors: Who the policy applies to (Users or Groups)
2. Privileges: Which privileges should be assigned to the Actors (e.g. "View Analytics")

Note that platform policies do not include a specific "target resource" against which the Policies apply. Instead, they simply serve to assign specific privileges to DataHub users and groups.

Metadata Policies

Metadata policies determine who can do what to which Metadata Entities. For example,

• Who can edit Dataset Documentation & Links?
• Who can add Owners to a Chart?
• Who can add Tags to a Dashboard?

and so on.

A Metadata Policy can be broken down into 3 parts:

1. Resources: The 'which'. Resources that the policy applies to, e.g. "All Datasets".
2. Privileges: The 'what'. What actions are being permitted by a policy, e.g. "Add Tags".
3. Actors: The 'who'. Specific users, groups that the policy applies to.

Resources

Resources can be associated with the policy in a number of ways:

1. Resource types - The entity's type, for example: dataset, chart, dashboard
2. Resource URNs - Specific entity URNs to target
3. Tags - Assets tagged with specific tags
4. Domains - Assets within specific domains
5. Containers - Assets within specific containers (e.g., databases, schemas)
6. Glossary Terms or Term Groups - Assets annotated with specific glossary terms or any term within a term group (see Glossary-Based Policy Targeting below)

:::note Important Note The associations in the list above are an intersection or an AND operation. For example, if the policy targets 1. resource type: dataset and 3. resources tagged: 'myTag', it will apply to datasets that are tagged with tag 'myTag'. :::

Domain-Based Policy Targeting

Policies can be targeted to assets based on Domains. This allows you to apply permissions to all assets within a specific business domain.

When you target a policy by domain, the policy applies recursively to any asset that belongs to that domain as well as any assets in nested child domains.

Example: A policy targeting the "Marketing" domain will apply to all datasets, dashboards, and other assets assigned to that domain, as well as assets in child domains like "Marketing Analytics" or "Marketing Campaigns".

Creating Assets with Domain-Scoped Access

A new asset does not have persisted domain metadata when DataHub performs its initial authorization check. As a result, a domain-scoped policy cannot grant the Create Entity privilege for that asset. This commonly affects ingestion users that need to create datasets and then manage only the datasets assigned to their domain.

Configure two metadata policies for this use case:

1. Creation policy: Target all assets of the required type, such as all datasets, and grant Create Entity to the ingestion user or group.
2. Domain policy: Target the asset type and domain, then grant the privileges that the actor needs after creation, such as View Entity Page, Edit Domain, or other aspect privileges.

Create the asset and its domain aspect in the same creation batch using the CREATE_ENTITY change type. The creation policy authorizes the initial write. After the domain aspect is persisted, the domain policy applies to subsequent requests.

:::caution The creation policy authorizes all aspects included in the initial entity creation, not only the domain aspect. Limit this policy to the necessary actors and entity types, and grant ongoing edit privileges through the domain-scoped policy. :::

:::caution View-based access control performance When view-based access control is enabled, domain filters can be expensive: DataHub walks the domain hierarchy for each authorization check. Prefer ownership-based policies for entity access, and use domain filters mainly for domain-entity visibility or Cloud discovery boundaries. Keep domain hierarchies shallow. :::

Container-Based Policy Targeting

Policies can be targeted to assets based on Containers (e.g., databases, schemas, projects). This allows you to apply permissions based on technical organization.

When you target a policy by container, the policy applies recursively to all assets within that container as well as any assets in nested child containers.

Example: A policy targeting a "production" database container will apply to all schemas within that database and all tables within those schemas.

:::caution View-based access control performance When view-based access control is enabled, container filters walk the container hierarchy sequentially for each authorization check. Avoid container-based policies on deep warehouse hierarchies (database → schema → table). See Domains and containers for alternatives. :::

Glossary-Based Policy Targeting

Policies can be targeted to assets based on Glossary Terms or Glossary Term Groups. This allows you to apply permissions based on business vocabulary rather than technical properties.

When you target a policy by glossary terms or groups:

• Individual Terms: The policy applies to any asset annotated with that specific glossary term
• Term Groups: The policy applies recursively to assets annotated with any term within that group, including all nested child terms and groups

This works similarly to domain and container-based policies, automatically covering assets as your glossary evolves.

Example: A policy targeting the "Sensitive Data" term group will apply to all assets tagged with child terms like "PII", "PHI", or any terms in nested groups, without requiring policy updates when new terms are added to the hierarchy.

Privileges

Check out the list of privileges here . Note, the privileges are semantic by nature, and does not tie in 1-to-1 with the aspect model.

All edits on the UI are covered by a privilege, to make sure we have the ability to restrict write access. See the Reference section below.

Actors

We currently support 3 ways to define the set of actors the policy applies to:

1. list of users (or all users)
2. list of groups (or all groups)
3. owners of the entity

:::note Important Note Unlike resources, the definitions for actors are a union of the actors. For example, if user 1. Alice is associated with the policy as well as 3. owners of the entity. This means that Alice OR any owner of the targeted resource(s) will be included in the policy. :::

Managing Policies

Policies can be managed on the page Settings > Permissions > Policies page. The Policies tab will only be visible to those users having the Manage Policies privilege.

Out of the box, DataHub is deployed with a set of pre-baked Policies. The set of default policies are created at deploy time and can be found inside the policies.json file within metadata-service/war/src/main/resources/boot. This set of policies serves the following purposes:

1. Assigns immutable super-user privileges for the root datahub user account (Immutable)
2. Assigns all Platform privileges for all Users by default (Editable)

The reason for #1 is to prevent people from accidentally deleting all policies and getting locked out (datahub super user account can be a backup) The reason for #2 is to permit administrators to log in via OIDC or another means outside of the datahub root account when they are bootstrapping with DataHub. This way, those setting up DataHub can start managing policies without friction. Note that these privilege can and likely should be altered inside the Policies page of the UI.

:::note Pro-Tip To login using the datahub account, simply navigate to <your-datahub-domain>/login and enter datahub, datahub. Note that the password can be customized for your deployment by changing the user.props file within the datahub-frontend module. Notice that JaaS authentication must be enabled. :::

Configuration

By default, the Policies feature is enabled. This means that the deployment will support creating, editing, removing, and most importantly enforcing fine-grained access policies.

In some cases, these capabilities are not desirable. For example, if your company's users are already used to having free reign, you may want to keep it that way. Or perhaps it is only your Data Platform team who actively uses DataHub, in which case Policies may be overkill.

For these scenarios, we've provided a back door to disable Policies in your deployment of DataHub. This will completely hide the policies management UI and by default will allow all actions on the platform. It will be as though each user has all privileges, both of the Platform & Metadata flavor.

To disable Policies, you can simply set the AUTH_POLICIES_ENABLED environment variable for the datahub-gms service container to false. For example in your docker/datahub-gms/docker.env, you'd place

AUTH_POLICIES_ENABLED=false

REST API Authorization

Policies only affect REST APIs when the environment variable REST_API_AUTHORIZATION is set to true for GMS. Some policies only apply when this setting is enabled, marked above, and other Metadata and Platform policies apply to the APIs where relevant, also specified in the table above.

Designing policies for view-based access control

This section covers how to design access policies when view-based access control (VBAC) is enabled — that is, when policies restrict what users can view or discover, not just edit. Poor policy design in VBAC deployments can cause slow search, slow entity pages, and high load on the metadata service.

When this guidance applies

When VBAC is enabled (Cloud Search Access Controls or OSS VIEW_AUTHORIZATION_ENABLED), entity types are restricted by default. Types marked viewUnrestricted: true in entity-registry.yml, plus optional VIEW_UNRESTRICTED_ENTITY_TYPES / _ADD / _REMOVE overlays (see Environment Variables), bypass view checks. Stock _ADD covers the previous unrestricted set minus registry-flagged types; trim with VIEW_UNRESTRICTED_ENTITY_TYPES_REMOVE (for example schemaField,document) when you want those types under view policy. Once schemaField is restricted, View Entity Page inherits from the parent dataset encoded in the schemaField URN (then a direct column grant). Search Access Controls (query-time search filtering) remain DataHub Cloud–only; on OSS the unrestricted list only affects entity-page / masking behavior. Cloud operators: see also Entity types that bypass view checks.

Performance considerations

Policy evaluation is grant-only and first-match-wins: DataHub checks policies in order until one grants access. Under VBAC, view and discovery privileges trigger authorization on search results, entity pages, and browse — often once per entity.

Keep these factors in mind when designing policies:

Groups

Groups are the preferred way to assign policies to teams. When VBAC is enabled:

• Sync from your IdP when possible (Okta, Azure AD) so group membership stays current without manual updates.
• Assign one group per policy boundary — e.g. a "Team A Developers" group on a single owner-based policy, rather than listing many groups on one policy.
• Limit overlapping group membership — users in many groups increase matching and role-resolution cost and can impact performance. DataHub recommends limiting each user to no more than 200 groups for best performance.
• Prefer group-level policies over per-user policies — easier to maintain and fewer actor entries to evaluate.

For SCIM-based group provisioning, see Okta identity provisioning and Microsoft Entra identity provisioning.

Domains and containers

Domains organize metadata for curation; they can also be used as policy resource filters. Under VBAC, using domains as the primary boundary for entity view access is expensive because DataHub resolves parent domains recursively on every authorization check.

Prefer:

• Ownership-based policies for dataset and other entity access (see Ownership-based access)
• Domain filters only for domain entity visibility (so users can navigate the domain tree) or for Cloud Search Access Controls discovery boundaries
• Shallow domain hierarchies when domain filters are required

Avoid:

• One full-metadata view policy per team domain when ownership can express the same boundary
• Deep nested domain trees as the primary access boundary
• Container-based view policies on deep warehouse hierarchies

Roles and VBAC

When VBAC is enabled, Admin, Editor, and Reader roles override view-based policy restrictions. Users assigned any of these roles can view all entities regardless of domain- or ownership-based view policies.

Do not assign Editor or Reader to users who should have restricted discovery. Reserve the Admin role for platform operators. See Roles and Search Access Controls.

Recommended patterns

These patterns assume VBAC is enabled and separate teams need isolated metadata visibility. Use generic team and domain names when implementing.

Pattern A — Multi-team isolation (ownership-first)

Use when separate teams or business units should only access their own metadata:

1. Platform Admins — Admin role only (hardcoded super-privileges).
2. Central platform team — one metadata policy: actors = IdP group(s), resources = broad (by entity type), privileges = view/edit as needed.
3. Team-scoped users — one owner-based metadata policy per team: actors = resource owners (group ownership type), privileges include view/edit metadata; assign ownership at ingestion (see Ownership-based access).
4. Domain visibility only — one narrow policy per team targeting domain entities (not datasets) so users can navigate the domain structure without domain-scoped dataset policies.

Resource matching via ownership uses a single ownership aspect fetch instead of walking domain parents on every dataset.

Pattern B — Domain-scoped discovery (DataHub Cloud)

On DataHub Cloud with Search Access Controls enabled:

• Use domain-based View Entity policies for discovery boundaries.
• Keep the domain hierarchy shallow, policy count low, and do not assign Editor/Reader roles to restricted users.

Anti-patterns

• One policy per user instead of per group.
• Many overlapping domain policies for the same privilege (e.g. one full-metadata policy per team domain instead of consolidating).
• Deep nested domain trees as the primary access boundary.
• Container-based policies on deep database → schema → table chains.
• Assigning Reader or Editor while expecting domain or ownership isolation.
• Relying on OSS VIEW_AUTHORIZATION_ENABLED alone to prevent users from discovering other teams' data in search (OSS does not filter search at query time).
• Large numbers of URN-specific policies instead of tags plus one tag-based policy.

Ownership-based access

Assign ownership at ingestion so owner-based policies can grant view and edit access without domain-scoped resource filters. Use the pattern_add_dataset_ownership transformer to match dataset URNs and assign group owners by pattern.

Schema ownership: Ingestion recipes that assign ownership only to datasets may leave schemas without owners. If team-scoped users need to view schemas via owner-based policies, assign schema ownership through the UI or extend ingestion to cover schema entities.

Troubleshooting slow search or UI

If search or entity pages feel slow after enabling VBAC:

1. Count active policies — reduce overlapping or redundant policies.
2. Review domain-scoped view policies — replace dataset boundaries with ownership-based policies where possible.
3. Check domain depth — flatten nested domains used in policy filters.
4. Review group membership — reduce users in many overlapping groups; aim for no more than 200 groups per user.
5. Check role assignments — Editor/Reader on restricted users won't cause slowness but indicates misconfiguration if isolation is expected.
6. Wait for cache refresh — policy changes may take up to POLICY_CACHE_REFRESH_INTERVAL_SECONDS (default 120) to apply.

Policy propagation

Policy definitions are cached in GMS and refreshed periodically. After creating or editing policies, allow up to POLICY_CACHE_REFRESH_INTERVAL_SECONDS seconds (default 120) before changes fully propagate. See environment variables for configuration.

Reference

For a complete list of privileges see the privileges here.

Platform-level privileges

These privileges are for DataHub operators to access & manage the administrative functionality of the system.

Access & Credentials

| Platform Privileges | Description | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | | Generate Personal Access Tokens | Allow actor to generate personal access tokens for use with DataHub APIs. | | Manage Policies | Allow actor to create and remove access control policies. Be careful - Actors with this privilege are effectively super users. | | Manage Secrets | Allow actor to create & remove Secrets stored inside DataHub. | | Manage Users & Groups | Allow actor to create, remove, and update users and groups on DataHub. | | Manage All Access Tokens | Allow actor to create, list and revoke access tokens on behalf of users in DataHub. Be careful - Actors with this privilege are effectively super users that can impersonate other users. | | Manage User Credentials | Allow actor to manage credentials for native DataHub users, including inviting new users and resetting passwords | | | Manage Connections | Allow actor to manage connections to external DataHub platforms. |

Product Features

Entity Management

System Management

| Platform Privileges | Description | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --- | | Restore Indices API³ | Allow actor to use the Restore Indices API. | | | Get Timeseries index sizes API³ | Allow actor to use the get Timeseries indices size API. | | Truncate timeseries aspect index size API³ | Allow actor to use the API to truncate a timeseries index. | | Get ES task status API³ | Allow actor to use the get task status API for an ElasticSearch task. | | Enable/Disable Writeability API³ | Allow actor to enable or disable GMS writeability for data migrations. | | Apply Retention API³ | Allow actor to apply retention using the API. | | Analytics API access³ | Allow actor to use API read access to raw analytics data. | | Explain ElasticSearch Query API³ | Allow actor to use the Operations API explain endpoint. | | Produce Platform Event API³ | Allow actor to produce Platform Events using the API. | | Manage System Operations | Allow actor to manage system operation controls. This setting includes all System Management privileges. |

Common Metadata Privileges

These privileges are to view & modify any entity within DataHub.

Entity Privileges

Aspect Privileges

Proposals

Derived authorization rules

Some APIs authorize against related entities rather than only the URN in the request. These rules apply across GraphQL, Rest.li, and MCP ingestion (unless the change uses a system ingestion source).

Data Products

Domain URNs are read from the product's domains aspect, preferring domainAssociations and falling back to the legacy domains array. Duplicate entries are deduplicated. Products with no Domain associations are denied for product-side manage operations. Product and asset Domains do not need to match — authorization succeeds when either product-side manage or asset-side edit checks pass.

Known issue: Domain alignment is not enforced after membership is written. Changing a product's or asset's domains aspect does not re-validate or prune existing assets links.

Query entities

Query entities with no subjects are not readable when view authorization is enabled (fail-closed). Schema field subjects are resolved to their parent dataset for authorization. Edit Entity on a subject dataset also grants read access (same disjunction as write).

Schema field entities (view)

When schemaField is view-restricted, View Entity Page on a schema field succeeds if the actor can view the containing parent URN in the schemaField key (typically a dataset) or has a direct grant on the schemaField URN. This uses the same parent-candidate order as logical-parent writes.

On DataHub Cloud with Search Access Controls, query-time filters for columns are narrower than entity-page inheritance: domain / container / resource-owner criteria do not match schemaField docs, and TYPE = dataset policies exclude them. URN dataset grants can match columns via a Cloud-only prefix. Details: Columns (schemaField) after you restrict them.

View authorization is controlled by VIEW_AUTHORIZATION_ENABLED (see Environment Variables).

Logical parent (logicalParent aspect)

Setting a logical parent requires Edit Entity on both the child and the proposed parent. Clearing a logical parent requires Edit Entity on the child side only. There is no OR between child and parent — access to only one side is insufficient when setting a link.

Each side is evaluated independently. For a dataset, that side passes when the actor has Edit Entity on that dataset. For a schema field, that side passes when the actor has Edit Entity on the containing dataset or on the schema field URN. Child and parent may satisfy their respective checks via different grant types (for example, dataset grant on the physical side and schema-field grant on the logical side).

Applies to MCP ingestion, GraphQL (setLogicalParent), and OpenAPI logical-model relationship endpoints.

Specific Entity-level Privileges

These privileges are not generalizable.

Users & Groups

Dataset

Misc

Coming Soon

Experimental

Support for Policy Constraints based on entity sub-resources (tags, glossary terms, domains, containers, etc.) is currently in development and in an experimental phase.

Currently the only supported sub-resources are tags. These are supported through an additional parameter in DataHubPolicyInfo which is currently only modifiable via API, there is no UI option to configure it. Specifically the option is privilegeConstraints which takes a PolicyMatchFilter within the existing DataHubResourceFilter for a policy. This works similarly to the existing resource filter, but instead of applying to the main entity being acted on it applies to the subResource targeted in the action. For example, if the policy specifies it is constrained to tags that equal urn:li:tag:tag1 or urn:li:tag:tag2 for EDIT_DATASET_TAGS privilege, then assuming no other policies match, a user would only be able to apply those tags to the dataset. This is also supported with the NOT_EQUALS condition for preventing certain tags from being added/removed. These policies apply by default in the UI and can be configured to apply to API operations as well through the MCP_VALIDATION_PRIVILEGE_CONSTRAINTS environment variable which should be applied globally (GMS, MCE Consumer, and DataHub Upgrade specifically), which is enabled by default.

Example JSON of a policy with constraints:

{
  "actors": {
    "resourceOwners": false,
    "groups": [],
    "allGroups": false,
    "allUsers": false,
    "users": ["urn:li:corpuser:[email protected]"]
  },
  "lastUpdatedTimestamp": 0,
  "privileges": ["EDIT_ENTITY_TAGS", "EDIT_DATASET_COL_TAGS"],
  "editable": true,
  "displayName": "Ryan Policy",
  "resources": {
    "filter": { "criteria": [] },
    "allResources": false,
    "privilegeConstraints": {
      "criteria": [
        {
          "field": "URN",
          "condition": "EQUALS",
          "values": ["urn:li:tag:PII", "urn:li:tag:Business Critical"]
        }
      ]
    }
  },
  "description": "",
  "state": "ACTIVE",
  "type": "METADATA"
}

mutation {
  createPolicy(
    input: {
      type: METADATA
      name: "my-policy"
      state: ACTIVE
      description: "My policy"
      privileges: ["EDIT_ENTITY_TAGS"]
      actors: {
        allUsers: true
        users: []
        groups: []
        resourceOwners: true
        allGroups: true
      }
      resources: {
        allResources: true
        resources: []
        filter: { criteria: [] }
        policyConstraints: {
          criteria: [
            {
              field: "URN"
              values: ["urn:li:tag:PII", "urn:li:tag:Business Critical"]
              condition: EQUALS
            }
          ]
        }
      }
    }
  )
}

Feedback / Questions / Concerns

We want to hear from you! For any inquiries, including Feedback, Questions, or Concerns, reach out on Slack!