Access control model

Important

Lakewatch is in Private Preview. To request access, reach out to your Azure Databricks account team.

Lakewatch access control is governed by Unity Catalog. Lakewatch resources are Unity Catalog securables that live in a catalog and schema you choose, and you grant access to them using Unity Catalog privileges. Access is inherited down the Unity Catalog hierarchy, so a grant on a catalog or schema applies to the Lakewatch resources beneath it.

Principals

Access is granted to principals: individual users, service principals (identified by name or applicationId), and groups. Lakewatch does not require any predefined roles or groups, and you can use any identity that Unity Catalog supports. For a recommended team-based setup that maps groups to security roles, see Set up access control.

Lakewatch resources as Unity Catalog securables

These Lakewatch resources are Unity Catalog securables and live under a catalog and schema that you choose:

• Datasources
• Detection rules

You organize them like any other Unity Catalog data, for example a catalog per environment (dev/staging/prod) and a schema per team. See Deployment models for suggested patterns.

Two groups of resources are governed by Unity Catalog but handled differently:

• Queries are managed through the Lakewatch app, using their own permission levels rather than the privileges you grant on datasources and detection rules.
• Signals and alerts are derived from detection rules: a rule produces signals, which are collated into alerts. They are not separate securables, so you do not grant on them directly. The security-data privileges (READ_SECURITY_DATA and UPDATE_SECURITY_DATA) on the parent rule or datasource control access to them (see Inheritance).

Environments and folders

Lakewatch registers the Unity Catalog catalogs and schemas that hold your resources as environments and folders:

• An environment is a catalog registered with Lakewatch (the top-level scope for its resources). An environment is available only from the workspace its catalog is bound to (see Workspace-catalog binding).
• A folder is a schema registered with Lakewatch under that catalog. Datasources and detection rules live in folders, and the privileges you grant on a folder apply to every resource it contains.

Environments and folders are a view over the catalog-per-environment, schema-per-team organization described in Deployment models; they don't change how access is granted. Folder permissions are Unity Catalog grants on the backing schema, so Privileges and Inheritance apply unchanged.

Privileges

You grant access with Unity Catalog privileges on a catalog, schema, or individual resource. Lakewatch defines privileges for reading a resource's configuration, managing the resource, managing its access, and reading or updating the security data (signals and alerts) it produces. For the complete list per resource type and what each privilege allows, see Roles and capabilities.

To create a resource, a principal needs USE CATALOG on the catalog and USE SCHEMA on the schema, plus the create privilege on that schema or catalog: CREATE_DATASOURCE for a datasource or CREATE_RULE for a detection rule. USE CATALOG and USE SCHEMA are traversal privileges: on their own they let a principal reach the catalog and schema but don't grant the ability to view a resource (that requires READ_METADATA) or to create one.

Because every Lakewatch resource is a Unity Catalog securable, any access to one (including simply viewing it) requires USE CATALOG on its catalog and USE SCHEMA on its schema, in addition to the privilege for the action itself. Unity Catalog applies this rule to every object it governs, such as a table, so granting someone view access to a datasource or detection rule (READ_METADATA) also means granting them USE CATALOG and USE SCHEMA, even though those two privileges on their own don't reveal the resource.

Inheritance

Access flows down the Unity Catalog hierarchy: catalog → schema → resource. A privilege granted on a catalog or schema applies to every Lakewatch resource beneath it, so you can grant broadly at the catalog or schema level instead of resource by resource.

The recommended setup grants each group's privileges at the catalog level, so they apply to every schema and resource in the catalog. To scope a group more narrowly, grant the same privileges at the schema level instead.

Signals and alerts are derived artifacts with no grants of their own. Access is inherited from the parent detection rule or datasource, but through a privilege that's separate from reading the parent's configuration:

• READ_METADATA on a detection rule or datasource lets you read that resource and its configuration. It does not, by itself, grant access to the signals and alerts the resource produces.
• Viewing those signals and alerts requires READ_SECURITY_DATA on the parent resource (a separate privilege from READ_METADATA).
• Updating an alert follows the UPDATE_SECURITY_DATA privilege on the parent resource. Signals are immutable.

Ownership

The principal who creates a Lakewatch resource becomes its owner, with full control of the resource including managing its access. Ownership can be transferred, and access can be shared more broadly by granting privileges to other principals.

Settings

Lakewatch settings are bound to a catalog and apply to all Lakewatch resources under it. A principal with MANAGE on the catalog can change that catalog's settings.

Onboarding and administration

A user who has USE CATALOG on a catalog, USE SCHEMA on a schema, and the relevant create privilege (CREATE_DATASOURCE or CREATE_RULE) can create Lakewatch resources there and owns what they create. In the workspace's default catalog, workspace users have USE CATALOG and USE SCHEMA by default, but CREATE_DATASOURCE and CREATE_RULE are not granted by default, so a user must be granted the relevant create privilege before they can create Lakewatch resources there. To set up Lakewatch for a team, follow Set up access control, which creates the groups, a run-as service principal, and the grants required. You can delegate management of a set of resources by granting MANAGE on the catalog or schema.

Access control is primarily owner-based: a privilege check is satisfied by an explicit grant or by owning the resource, and Lakewatch has no separate administrator override of its own. Account admins and metastore admins can still take ownership or grant themselves MANAGE through Unity Catalog's admin privileges. If a resource's owner is lost (for example, the person leaves or a service principal is deleted) and no other principal holds MANAGE, access can be hard to recover, so Databricks recommends owning production resources with a group. See Deployment models.

Scheduled jobs and the run-as principal

Each datasource and detection rule records a run-as principal. You choose it when you create the resource (your own identity, or a service principal you have permission to use), and only someone with MANAGE on the resource can change it. The scheduled ingestion and detection pipelines for the resource run as this principal, so it must be granted access to the tables that the datasource or detection rule references. To create a service principal for this purpose and grant it the access its scheduled jobs need, see Set up access control.