Lessons

Security & Compliance

Access control — least privilege and the object permission ladders

Apply least-privilege access controls to workspace objects (clusters, jobs, notebooks, pipelines) using permission levels and ownership rules.

Security starts with one discipline, and all of Section 7 applies it: give each person exactly the access their job needs — no more. This lesson is the coarse layer — permissions on the objects you work with (clusters, jobs, notebooks, pipelines) — before data grants, masks, and secrets. It's a set of small ladders you must know cold, so we anchor them to one idea and climb each.


The spine

Beat 1 — the anchor: least privilege + one ladder shape

Anchor. Grant the minimum permission the role needs (least privilege). And every workspace object exposes the same shape of ladder — see it → operate it → manage it — with object-specific names. Answer any "minimal permission to do X" question by placing X on that ladder: is X reading, running/operating, or changing the thing itself?

Two rules fall straight out: default to Can View/Can Run, never Can Manage, and grant to groups, not individuals (membership changes propagate everywhere at once).

Beat 2 — the cluster ladder (most-tested), by prediction

Rungs, each including the ones below: No Permissions < Can Attach To < Can Restart < Can Manage.

Predict: minimal permission to (a) view a cluster's Spark UI/metrics, (b) start a terminated auto-terminating cluster, (c) edit its permissions?

LevelUnlocksAnswer
Can Attach Toattach a notebook; view Spark UI, logs, metrics(a) view metrics/Spark UI
Can Restartstart / stop / restart (+ attach)(b) start a terminated cluster
Can Manageedit config and ACLs(c) modify permissions

One exception to bank: viewing driver logs on a Standard (shared) access-mode cluster needs Can Manage, not the lower rungs — ordinary Spark UI/metrics is still just Can Attach To, but driver logs on shared is the elevated case.

Lock it. read-only → lowest (View/Read/Attach); operate/run → middle (Run/Restart/Manage-Run); change the object or its ACLs → top (Manage). Driver logs on shared = Can Manage.


The dials (skim now; return when a question needs one)

◆ The other ladders — same shape, different names

◆ Ownership — one user, never a group

Many workspace objects have an owner (IS_OWNER) with full control. The rule: an object's owner must be a single user — you cannot set a group as owner. Transferring a job's ownership to a "DevOps"/"finance" group fails ("Groups can not be owners"), even with Can Manage. (Contrast UC data objects, where ownership can be a group — [Unity Catalog privileges — the three-level traversal and delegation](/lessons/s7-uc-privileges/).)

◆ Isolation as access control

Takeaways (rebuild it from these)

  1. Least privilege: minimum per role, default View/Run over Manage, grant to groups.
  2. Cluster ladder: Can Attach To (attach + Spark UI/metrics) < Can Restart (start/stop) < Can Manage (config + ACLs). Driver logs on a shared cluster = Can Manage.
  3. Same view → operate → manage shape: notebooks (Read/Run/Edit/Manage), jobs (View/Manage-Run/Manage), pipelines (View/Run/Manage). Derive by what the action does.
  4. Workspace-object ownership = one user, never a group (group owner transfer fails).
  5. Isolation is access control: dev/test/prod (read-only on prod data); bronze/silver/gold in separate databases for container ACLs.

Before you move on — say these without scrolling up

  1. The one ladder shape every object shares — and the two rules least-privilege gives you.
  2. View Spark UI vs start a terminated cluster vs edit its ACLs — which rung each?
  3. The driver-logs-on-shared exception.
  4. Transfer a job's ownership to a group — what happens?

Next: the data side — Unity Catalog privileges, the three-level traversal that trips everyone, and delegating admin without granting admin → [Unity Catalog privileges — the three-level traversal and delegation](/lessons/s7-uc-privileges/).

Prerequisites

Leads to