Skip to main content
Last updated on

Tutorial: Use an RBAC role for workspace administration

Use role-based access control (RBAC) to separate everyday work from tasks that require workspace admin permissions in Databricks. Users assume an admin role when needed and return to their user identity afterward, keeping administrative permissions out of their everyday sessions.

Scenario​

The site reliability engineers (SREs) in sre-team have standing workspace admin access through direct or inherited membership in the workspace's admins system group. You create an empty role-workspace-admin group, grant sre-team permission to assume it, and add the role to admins.

After testing the role, you remove standing admin access for the SREs you're moving to the role while preserving their everyday workspace access. Other workspace administrators keep their existing access. SREs choose when to assume the role and when to switch back. This setup does not configure approval workflows or automatic expiry of elevated access.

Prerequisites​

  • A workspace enabled for identity federation, with RBAC enabled. See Enable RBAC.
  • Account admin or workspace admin permissions to create the role, grant the Assume permission, and assign it to the workspace. See Who can manage groups?.
  • Workspace admin permissions to manage the workspace's admins group and entitlements.
  • An account group containing the SREs you want to configure. This tutorial uses sre-team. Substitute your own group name throughout.
  • An SRE from sre-team who can participate in validation using their own sign-in, separate from the administrator making the configuration changes.
  • An audit reader with access to system.access.audit. If the test workspace is not enabled for Unity Catalog, use a Unity Catalog-enabled workspace in the same account and cloud region to query audit events. See Verify audit attribution.

Step 1: Create the role​

For this tutorial, create an empty account group to serve as the role.

  1. As an account admin, log in to the account console.
  2. In the sidebar, click User management.
  3. On the Groups tab, click Add group.
  4. Enter role-workspace-admin. Do not add members.
  5. Click Confirm.
  6. Assign the group directly to the workspace with Workspace access. See Assign a group to a workspace.
important

Keep this role empty. After you add the role to admins, a member of the role inherits workspace admin permissions as their user identity.

Manage permission allows changes to the role's membership and grants of the Assume permission. Review the role's Permissions tab and limit Manage to the administrators responsible for controlling access to it. If account admins should control this role, create it in the account console to avoid automatically granting Manage to a workspace admin. See Who can manage groups?.

Create a separate admin role for each workspace so that permission to assume one role does not grant administration in multiple workspaces.

Step 2: Grant the SREs permission to assume the role​

Grant the Assume permission to sre-team using either method:

  1. As an account admin, open the account console and click User management.
  2. On the Groups tab, click role-workspace-admin.
  3. Click the Permissions tab, then click Grant access.
  4. Search for and select sre-team, select Assume, and click Save.

Members of sre-team can now assume the role. To change who can assume it, manage this group's membership or its grant of the Assume permission. When you withdraw access, check for other grants or memberships that also permit the user to assume the role.

Step 3: Add the role to the workspace's admin group​

As a workspace admin, add the role to admins:

  1. In the workspace, click your username in the top bar and select Settings.
  2. Click Identity and access.
  3. Next to Groups, click Manage.
  4. Select admins.
  5. On the Members tab, click Add members.
  6. Select role-workspace-admin, then click Confirm.

The role inherits workspace admin permissions from admins. The SREs have permission to assume this role without being members of it.

Step 4: Check role access and everyday access​

Before you change standing admin access, one of your SREs signs in to the workspace with their own account and completes these checks:

  1. Click the workspace name in the top bar and hover over the current workspace.
  2. Select role-workspace-admin from the role switcher.
  3. Verify that the workspace reloads with the role name under the workspace name.
  4. Open Settings > Identity and access, then click Manage next to Groups. Verify that you can open the admins group's Members tab. This check does not require changing any membership.
  5. Return to the role switcher and select your username.

As the workspace admin, also verify that sre-team is assigned to the workspace with the access entitlements its members need for everyday work:

  • Workspace access: Grants access to core workspace features such as notebooks, jobs, models, and pipelines.
  • Databricks SQL access: Grants access to Databricks SQL features, including dashboards, queries, and SQL warehouses.

If the SREs receive these entitlements only through admins, grant them to sre-team explicitly. This preserves their everyday access after you remove standing admin membership. See Access entitlements.

Step 5: Remove the selected SREs' standing admin access​

As the workspace admin, review the selected SREs' direct and inherited membership in admins:

  1. Open Settings > Identity and access > Groups > Manage.
  2. Open admins, then its Members tab.
  3. Remove the selected SREs' direct memberships and remove sre-team if it is a direct member. Keep role-workspace-admin and unrelated administrators.
  4. Check for other groups the selected SREs belong to, including those groups' parent groups, that still give them admin access. If a shared group also contains people who must retain admin access, give those people admin access another way before you remove the shared group from admins. Changing account-group membership can also affect access outside this workspace.

Keep the SREs' everyday workspace assignments and the grant of the Assume permission from Step 2. Removing standing admin access requires addressing each path into admins, not just a single direct membership.

Step 6: Verify elevation and return​

After you remove standing admin access, the same SRE verifies these results in their browser session:

  1. While acting as your user identity, refresh the workspace and verify that the workspace admin settings checked in Step 4 are unavailable.
  2. Use the role switcher to assume role-workspace-admin.
  3. Verify that you can open those admin settings and view the admins group's members.
  4. After finishing the administrative task, use the role switcher to select your username.
  5. Verify that those admin settings are unavailable again. Your everyday workspace access remains available.

Switching back changes the identity used by this browser session. It doesn't change a separately authenticated Databricks CLI profile or revoke its tokens. The admin role owns any assets that you create while acting as the role.

Step 7: Verify audit attribution​

To inspect activity under the admin role, run this query as the audit reader. Replace <workspace-id> with the ID of the test workspace:

SQL
SELECT event_time, service_name, action_name,
       identity_metadata.run_by, identity_metadata.run_by_display_name,
       identity_metadata.run_as, identity_metadata.run_as_display_name
FROM system.access.audit
WHERE workspace_id = '<workspace-id>'
  AND identity_metadata.run_as_display_name = 'role-workspace-admin'
  AND event_date >= current_date() - INTERVAL 1 DAY
ORDER BY event_time DESC;

Check the events for the SRE's test session. identity_metadata.run_by identifies the SRE who initiated each request, and run_as identifies the admin role used for authorization. The query filters on run_as_display_name, the role's human-readable name. Audit data is updated throughout the day, so a recent event might not appear immediately. See Identity metadata reference.

Optional: Use separate Databricks CLI profiles​

To perform administrative work with the Databricks CLI, authenticate separately for everyday and admin work. The token-management check in this section requires personal access tokens to be enabled and token management to be available in the workspace. See Monitor and revoke personal access tokens.

The participating SRE installs the Databricks CLI as described in Install or update the Databricks CLI. They log in using their own sign-in, with a named profile for everyday work and another for the admin role:

Bash
databricks auth login --host <workspace-url> --profile everyday
databricks auth login --host <workspace-url> --profile ws-admin

For everyday, the SRE selects their user identity under Authorize as.. in the browser. For ws-admin, they select role-workspace-admin.

The SRE compares this read-only admin command using each profile:

Bash
databricks token-management list --profile everyday
databricks token-management list --profile ws-admin

The everyday profile receives a permission error. The admin profile can list the token metadata. The SRE uses --profile everyday for subsequent everyday commands. Selecting that profile does not invalidate the admin profile. See Databricks CLI.

Clean up​

Keep the configuration if it is the access model you intend to use. For a temporary test, restore the SREs' original admin memberships before removing the role from admins or withdrawing the Assume permission. Review any assets owned by the role before deleting it.

Next steps​

On this page