Skip to content

SYSTEM Cited by 1 source

Unity Catalog Governed Tags

Governed Tags are Unity Catalog's account-level vocabulary of keys / key-value pairs (e.g. sensitivity:confidential, pii:ssn) that can be attached to catalogs, schemas, tables, and columns, with parent-to-child inheritance and separate CREATE / MANAGE permissions distinct from data-owner permissions on the tagged objects. Reached General Availability on 2026-05-13 (Source: sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags).

Governed Tags are the attribute foundation that Unity Catalog ABAC policies build on: "an account-level vocabulary of keys and values that standardizes how data is described across an account, with permissions that control who can apply which tags to which objects" (Source: same). See concepts/governed-tag for the broader concept; this page covers the Unity Catalog implementation.

Architectural shape

       account
          │
          ├── tag-taxonomy: defined, MANAGE-permissioned at account level
          │     │
          │     ├── sensitivity:public
          │     ├── sensitivity:confidential
          │     ├── pii:ssn
          │     ├── pii:email
          │     └── compliance:hipaa
          │
          └── workspaces / metastores
                │
                ├── catalog A           [tag: sensitivity:confidential]
                │     │                  ├── inherits to all schemas
                │     │                  └── inherits to all tables
                │     │                         └── inherits to all columns
                │     ├── schema A1
                │     │     └── table customers
                │     │           ├── column ssn  [tag: pii:ssn → applies ABAC mask]
                │     │           └── column email [tag: pii:email]
                │     └── schema A2
                │
                └── catalog B

GA-disclosed properties

Account-level vocabulary

Tags are defined once at the account level rather than per-table or per-workspace. This is what makes a single ABAC policy referencing pii:ssn plausibly cover every relevant column across the entire account.

Inheritance from parent to child

Tags applied to a catalog automatically apply to every schema, table, and column under that catalog, unless overridden. "Tags are key or key-value pairs (like sensitivity:confidential or pii:ssn) that attach to catalogs, schemas, tables, and columns, and inherit from parent to child objects." (Source: same.)

This matters because ABAC's "a single policy can cover many matching tables" claim depends on tags reaching all tables — manual per-table tagging would put the human-effort tax back into the system that governance was trying to remove.

Full lifecycle: SQL + REST API + UI + Terraform

GA shipped tag CRUD via SQL DDL (CREATE, ALTER, DROP, SHOW, DESCRIBE GOVERNED TAG), the REST API, the Databricks UI, and Terraform. "Admins can create, modify, and inspect tags using SQL […] as well as the UI, REST API, and Terraform. This enables easy automation and integration into existing workflows." (Source: same.)

The SQL DDL surface matters because GitOps-style policy + tag management ships as part of the same SQL migration apparatus as schema changes, which is the integration-without-handoff property the GA story emphasises.

Permission separation: CREATE vs MANAGE

  • Workspace admins receive CREATE by default (configurable). They can create new tags but not change tag-taxonomy governance.
  • Account admins receive MANAGE and CREATE. They control which tags exist account-wide.

"Allowing flexible control over tag governance" is the design intent (Source: same). The architectural property is that tag applicability (which tables get tagged with which tags) is permissioned separately from the tag taxonomy (which tags exist) — both of which are permissioned separately from the data ownership of the tables themselves. This three-way permission split is what enables the separation-of-duties governance model.

Visibility into coverage and inheritance

"UI and APIs provide clearer insight into how tags are applied and inherited, helping teams track coverage, trace classification decisions, and audit changes." (Source: same.) Tag coverage is itself an observable governance property; UI surfaces show which columns are tagged, which inheritances apply, and the audit trail of changes.

What's not disclosed

  • Storage / indexing model: how tags are stored in the Unity Catalog metadata DB; whether tag indexes exist for ABAC policy evaluation efficiency.
  • Override semantics: when a child object is explicitly tagged with a value different from the inherited parent tag, the precedence / merge / shadowing rules.
  • Tag dependencies / hierarchies: whether tags themselves can be hierarchical (e.g., pii:ssn implies pii:any).
  • Cardinality limits: how many distinct tags an account can have, how many tags a single object can carry.
  • Multi-tenancy: how the account-level vocabulary interacts with multi-tenant deployments where workspaces serve different customer cohorts.
  • Audit retention: how long tag-application audit records persist.

Seen in

Last updated · 542 distilled / 1,571 read