Roles and capabilities

Important

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

Lakewatch governs each resource type with Unity Catalog privileges. This reference lists the privileges for datasources, detection rules, signals, alerts, and queries, and the capability each one grants.

How privileges are organized

Each Lakewatch resource (datasource and detection rule) has two groups of privileges:

• Resource privileges govern the resource itself: reading its configuration, managing it, and managing its access.
• Security-data privileges govern the resource's outputs: the signals and alerts derived from it.

You can grant a privilege directly on a resource, or grant it on the parent schema or catalog and let it inherit down to the resources beneath.

Recommended roles

Databricks recommends four groups that map to the roles on a security team. Each group receives a fixed set of privileges on the Lakewatch catalog. For the commands that create these groups and apply these grants, see Set up access control.

Group	Privileges on the catalog
lakewatch-admins	USE CATALOG, USE SCHEMA, MANAGE, READ_METADATA, SELECT, MODIFY, CREATE_DATASOURCE, CREATE_RULE, CREATE_SECRET, READ_SECURITY_DATA, UPDATE_SECURITY_DATA
lakewatch-data-engineers	USE CATALOG, USE SCHEMA, CREATE_DATASOURCE, CREATE_SECRET, SELECT, MODIFY, CREATE TABLE, CREATE SCHEMA
lakewatch-detection-engineers	USE CATALOG, USE SCHEMA, CREATE_RULE, READ_METADATA, READ_SECURITY_DATA, SELECT
lakewatch-analysts	USE CATALOG, USE SCHEMA, READ_SECURITY_DATA, UPDATE_SECURITY_DATA, SELECT, READ_METADATA

What each role can do

These privileges are granted on the catalog, so they inherit to every schema and resource beneath it. A group's access therefore spans all Lakewatch resources in that catalog, including resources other users created, not only the ones its own members create. This access comes from the catalog grant, not from an administrator override: because the access control model has no override, a group reaches exactly what its grants cover and nothing in a catalog where it holds no grant.

• lakewatch-admins manage the entire catalog: they create, view, edit, delete, and re-share any datasource or detection rule (MANAGE), read and update all of the security data those resources produce, query all data (SELECT), and change the catalog's Lakewatch settings.
• lakewatch-data-engineers create and own datasources, create tables and schemas, and query and write data across the catalog (SELECT, MODIFY).
• lakewatch-detection-engineers create detection rules, view any datasource or detection rule in the catalog (READ_METADATA), read the security data those resources produce (READ_SECURITY_DATA), and query data (SELECT).
• lakewatch-analysts work the alert queue across the catalog: they read and update the security data (alerts and signals) produced by any rule or datasource (READ_SECURITY_DATA, UPDATE_SECURITY_DATA), query the underlying tables and signals (SELECT), and view resource configuration (READ_METADATA).

A group reaches another member's resources only as far as its granted privileges extend: viewing a resource needs READ_METADATA, and working with its security data needs the matching security-data privilege. Ownership always adds full control, so whoever creates a resource can manage it regardless of group membership, and changing a resource or its access requires MANAGE or ownership.

Share a resource with your team

You own what you create, and ownership includes the right to grant access to others. To share a detection rule or datasource, grant the privilege that matches what the recipient should do:

• To let them view it, grant READ_METADATA.
• To let them see the alerts and signals it produces, grant READ_SECURITY_DATA.
• To let them edit, delete, or co-manage it, grant MANAGE.

You do not need MANAGE just to make a resource visible to the team. MANAGE is only for letting others change it. With the recommended setup, the team groups already hold these privileges on the shared catalog, so resources you create there are shared with the team automatically. Grant on an individual resource only when you need to widen access beyond the group defaults.

Datasources and detection rules

Datasources and detection rules share the same resource and security-data privileges. They differ only in the create privilege (CREATE_DATASOURCE for a datasource, CREATE_RULE for a detection rule):

Privilege	Grants
READ_METADATA	Read the resource and its configuration.
MANAGE	Manage the resource: update, delete, and transfer ownership. Doesn't by itself grant read or data access.
MANAGE_ACCESS_CONTROL	Grant and revoke privileges on the resource.
READ_SECURITY_DATA	Read the security data the resource produces (its signals and alerts).
UPDATE_SECURITY_DATA	Update that security data (for example, update an alert).

To create a datasource, you need USE CATALOG on the catalog, USE SCHEMA on the schema, and CREATE_DATASOURCE on the parent schema. To create a detection rule, you need the same USE CATALOG and USE SCHEMA privileges, plus CREATE_RULE on the parent schema.

Access to a resource another user owns follows these same privileges, whether it is a datasource or a detection rule:

• To view it, you need READ_METADATA on the resource, or on a schema or catalog above it.
• To edit, delete, or transfer it, you need MANAGE, or you must be its owner. MANAGE alone does not let you view a resource; pair it with READ_METADATA.
• To change who can access it, you need MANAGE_ACCESS_CONTROL (included in MANAGE), or ownership.

In every case, the principal also needs USE CATALOG on the catalog and USE SCHEMA on the schema that contain the resource, because a datasource or detection rule is a Unity Catalog securable that a principal must be able to reach before any privilege on it takes effect. This is why granting view access alone (READ_METADATA) isn't enough without USE CATALOG and USE SCHEMA. See Access control model.

Signals and alerts (derived artifacts)

Signals and alerts are derived artifacts. They are not separate securables, so the security-data privileges on the parent detection rule or datasource control access to them:

To…	You need this on the parent rule or datasource
View or list signals and alerts	READ_SECURITY_DATA
Update an alert	UPDATE_SECURITY_DATA

Signals are immutable, so only alerts can be updated.

Queries

You manage query access through the Lakewatch app, using these permission levels:

Permission level	Grants
CAN_VIEW	View the query and its results.
CAN_RUN	Run the query.
CAN_EDIT	Edit and save the query.
CAN_MANAGE	Manage the query, including its access. The query's creator gets this.