หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
Important
Lakewatch is in Beta. Workspace admins can control access to this feature from the Previews page. See Manage workspace-level previews.
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, or a small team whose members trust each other with full access, works with Lakewatch using the default access from setup.
- Team-based: A security team shares Lakewatch by giving each security role, such as detection engineers or analysts, the permission group it needs, and runs scheduled work as a service principal. This is the model Databricks recommends for production.
Single-user deployment
Set up Lakewatch with the Recommended configuration. It grants all account users Lakewatch admin on the environment and every Lakewatch permission on its folders, so anyone who can use the workspace can create, manage, and share Lakewatch resources. Each user owns what they create. Because all of these users can administer the environment, use this model only for evaluation or when everyone with workspace access should have full Lakewatch access.
Team-based deployment
For a security team, map groups to roles (administrators, data engineers, detection engineers, and analysts), make administrators Lakewatch admin on the environment, and give every other group a permission group on the folder it works in. For the step-by-step setup, 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. |