Deployment models

Preview

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

Lakewatch resources are Unity Catalog securables, so you organize and govern them the same way you do your data, with catalogs, schemas, and Unity Catalog grants. Choose a deployment model, then use catalogs and schemas to keep resources isolated as you scale.

Choose a deployment model

Lakewatch supports two deployment models:

• Single user: One person works with Lakewatch under their own identity. This needs no setup beyond access to a catalog and schema.
• Team-based: A security team shares Lakewatch using role-based access control (RBAC), with groups mapped to roles and a service principal for scheduled work. This is the model Databricks recommends for production.

Single-user deployment

Lakewatch requires no administrator onboarding. To create Lakewatch resources, a user needs USE CATALOG on the catalog, USE SCHEMA on the schema, and the create privilege for the resource (CREATE_DATASOURCE or CREATE_RULE), and they own 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 creating Lakewatch resources.

Team-based deployment

For a security team, map groups to roles (administrators, data engineers, detection engineers, and analysts), grant each group its privileges on the catalog, and run scheduled datasources and detection rules as a shared service principal. For the step-by-step setup, including the groups, the run-as service principal, and the grants, see Set up access control. For the privileges each role needs, see Roles and capabilities.

Organize with catalogs and schemas

As you scale to more teams and environments, use catalogs and schemas to keep resources isolated and governed. Lakewatch registers these catalogs and schemas as environments and folders, so the patterns below map directly onto them:

Pattern	What it does
Environment isolation by catalog	Keep separate dev, staging, and prod catalogs, each with its own rules, datasources, and queries. Workspace-catalog binding controls which environment a given workspace can reach.
Team isolation by schema	Within a catalog, group resources into schemas by the team that owns them (for example, prod.detections_threat_hunting, prod.detections_okta). Granting the create privilege plus USE SCHEMA on a schema scopes what a team can author.
Management delegation	Grant MANAGE on a catalog or schema to a team lead to delegate administration of everything beneath it, without granting workspace-admin or account-admin.
Group-owned production assets	Own production rules, datasources, and queries with a group rather than an individual, so access survives people changing roles or leaving. Use your identity provider's managed groups.
Service principals for execution	Run scheduled datasources and detection rules as a service principal owned by the operating team, keeping production execution decoupled from any individual's account.

Pattern	What it does
Environment isolation by catalog	Keep separate dev, staging, and prod catalogs, each with its own rules, datasources, and queries. Workspace-catalog binding controls which environment a given workspace can reach.
Team isolation by schema	Within a catalog, group resources into schemas by the team that owns them (for example, prod.detections_threat_hunting, prod.detections_okta). Granting the create privilege plus USE SCHEMA on a schema scopes what a team can author.
Management delegation	Grant MANAGE on a catalog or schema to a team lead to delegate administration of everything beneath it, without granting workspace-admin or account-admin.
Group-owned production assets	Own production rules, datasources, and queries with a group rather than an individual, so access survives people changing roles or leaving. Use your identity provider's managed groups.
Service principals for execution	Run scheduled datasources and detection rules as a service principal owned by the operating team, keeping production execution decoupled from any individual's account.