Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.databricks.com/aws/en/security/auth/access-control/ below:

Access control lists | Databricks Documentation

This article describes details about the permissions available for the different workspace objects.

In Databricks, you can use access control lists (ACLs) to configure permission to access workspace level objects. Workspace admins have the CAN MANAGE permission on all objects in their workspace, which gives them the ability to manage permissions on all objects in their workspaces. Users automatically have the CAN MANAGE permission for objects that they create.

For an example of how to map typical personas to workspace-level permissions, see the Proposal for Getting Started With Databricks Groups and Permissions.

You can manage workspace object permissions by adding objects to folders. Objects in a folder inherit all permissions settings of that folder. For example, a user that has the CAN RUN permission on a folder has CAN RUN permission on the alerts in that folder.

If you grant a user access to an object inside the folder, they can view the parent folder's name, even if they do not have permissions on the parent folder. For example, a notebook named test1.py is in a folder named Workflows. If you grant a user CAN VIEW on test1.py and no permissions on Workflows, the user can see that the parent folder is named Workflows. The user cannot view or access any other objects in the Workflows folder unless they have been granted permissions on them.

To learn about organizing objects into folders, see Workspace browser.

Ability

NO PERMISSIONS

CAN VIEW/CAN RUN

CAN EDIT

CAN MANAGE

View dashboard and results

x

x

x

Interact with widgets

x

x

x

Refresh the dashboard

x

x

x

Edit dashboard

x

x

Clone dashboard

x

x

x

Publish dashboard snapshot

x

x

Modify permissions

x

Delete dashboard

x

Ability

NO PERMISSIONS

CAN RUN

CAN MANAGE

See in alert list

x

x

View alert and result

x

x

Manually trigger alert run

x

x

Subscribe to notifications

x

x

Edit alert

x

Modify permissions

x

Delete alert

x

important

Users with CAN ATTACH TO permissions can view the service account keys in the log4j file. Use caution when granting this permission level.

Ability

NO PERMISSIONS

CAN ATTACH TO

CAN RESTART

CAN MANAGE

Attach notebook to compute

x

x

x

View Spark UI

x

x

x

View compute metrics

x

x

x

Terminate compute

x

x

Start and restart compute

x

x

View driver logs

x (see note)

Edit compute

x

Attach library to compute

x

Resize compute

x

Modify permissions

x

note

Secrets are not redacted from a cluster's Spark driver log stdout and stderr streams. To protect sensitive data, by default, Spark driver logs are viewable only by users with CAN MANAGE permission on job, dedicated access mode, and standard access mode clusters. To allow users with CAN ATTACH TO or CAN RESTART permission to view the logs on these clusters, set the following Spark configuration property in the cluster configuration: spark.databricks.acl.needAdminPermissionToViewLogs false.

On No Isolation Shared access mode clusters, the Spark driver logs can be viewed by users with CAN ATTACH TO or CAN MANAGE permission. To limit who can read the logs to only users with the CAN MANAGE permission, set spark.databricks.acl.needAdminPermissionToViewLogs to true.

See Spark configuration to learn how to add Spark properties to a cluster configuration.

Ability

NO PERMISSIONS

CAN VIEW

CAN RUN

CAN EDIT

CAN MANAGE

See in dashboard list

x

x

x

x

View dashboard and results

x

x

x

x

Refresh query results in the dashboard (or choose different parameters)

x

x

x

Edit dashboard

x

x

Modify permissions

x

Delete dashboard

x

Editing a legacy dashboard requires the Run as viewer sharing setting. See Refresh behavior and execution context.

Ability

NO PERMISSIONS

CAN CREATE

CAN USE

CAN MANAGE

Get database instance

x

x

x

List database instances

x

x

x

Create database instance

x

x

x

Create synced table

x

x

Create Unity Catalog database catalog

x

Modify Postgres roles

x

Delete database instance

x

Modify permissions

x

Pause database instance

x

Resume database instance

x

note

• All workspace users inherit the CAN CREATE permission.
• When performing operations that interact with Unity Catalog you need to have permissions on the Unity Catalog object:
  • Create Unity Catalog database catalog: Requires CREATE CATALOG on the Unity Catalog metastore.
  • Create synced table: Requires Unity Catalog permissions to read the source table, write to the destination schema, and write to the pipeline storage schema.

Ability

NO PERMISSIONS

CAN VIEW

CAN RUN

CAN MANAGE

IS OWNER

View pipeline details and list pipeline

x

x

x

x

View Spark UI and driver logs

x

x

x

x

Start and stop a pipeline update

x

x

x

Stop pipeline clusters directly

x

x

x

Edit pipeline settings

x

x

Delete the pipeline

x

x

Purge runs and experiments

x

x

Modify permissions

x

x

This table describes how to control access to feature tables in workspaces that are not enabled for Unity Catalog. If your workspace is enabled for Unity Catalog, use Unity Catalog privileges instead.

Ability

CAN VIEW METADATA

CAN EDIT METADATA

CAN MANAGE

Read feature table

X

X

X

Search feature table

X

X

X

Publish feature table to online store

X

X

X

Write features to feature table

X

X

Update description of feature table

X

X

Modify permissions

X

Delete feature table

X

::::

Ability

NO PERMISSIONS

CAN VIEW

CAN RUN

CAN EDIT

CAN MANAGE

Read file

x

x

x

x

Comment

x

x

x

x

Attach and detach file

x

x

x

Run file interactively

x

x

x

Edit file

x

x

Modify permissions

x

note

The workspace UI refers to view-only access as CAN VIEW, while the Permissions API uses CAN READ to represent the same level of access.

Ability

NO PERMISSIONS

CAN VIEW

CAN EDIT

CAN RUN

CAN MANAGE

List objects in folder

x

x

x

x

x

View objects in folder

x

x

x

x

Clone and export items

x

x

x

Run objects in the folder

x

x

Create, import, and delete items

x

Move and rename items

x

Modify permissions

x

note

The workspace UI refers to view-only access as CAN VIEW, while the Permissions API uses CAN READ to represent the same level of access.

Ability

NO PERMISSIONS

CAN VIEW/CAN RUN

CAN EDIT

CAN MANAGE

See in Genie space list

x

x

x

Ask Genie questions

x

x

x

Provide response feedback

x

x

x

Add or edit Genie instructions

x

x

Add or edit sample questions

x

x

Add or remove included tables

x

x

Monitor a space

x

Modify permissions

x

Delete space

x

View other users' conversations

x

x

Ability

NO PERMISSIONS

CAN READ

CAN RUN

CAN EDIT

CAN MANAGE

List assets in a folder

x

x

x

x

x

View assets in a folder

x

x

x

x

Clone and export assets

x

x

x

x

Run executable assets in folder

x

x

x

Edit and rename assets in a folder

x

x

Create a branch in a folder

x

Switch branches in a folder

x

Pull or push a branch into a folder

x

Create, import, delete, and move assets

x

Modify permissions

x

Ability

NO PERMISSIONS

CAN VIEW

CAN MANAGE RUN

IS OWNER

CAN MANAGE

View job details and settings

x

x

x

x

View results

x

x

x

x

View Spark UI, logs of a job run

x

x

x

Run now

x

x

x

Cancel run

x

x

x

Edit job settings

x

x

Delete job

x

x

Modify permissions

x

x

note

• The creator of a job has the IS OWNER permission by default.

• A job cannot have more than one owner.

• A group cannot be assigned the Is Owner permission as an owner.

• Jobs triggered through Run Now assume the permissions of the job owner and not the user who issued Run Now.

• Jobs access control applies to jobs displayed in the Lakeflow Jobs UI and their runs. It doesn't apply to:

  • Notebook workflows that run modular or linked code. These use the permissions of the notebook itself. If the notebook comes from Git, a new copy is created and its files inherit the permissions of the user who triggered the run.

  • Jobs submitted by API. These use the notebook's default permissions unless you explicitly set the access_control_list in the API request.

MLflow experiment ACLs are different for notebook experiments and workspace experiments. Notebook experiments cannot be managed independently of the notebook that created them, so the permissions are similar to notebook permissions.

To learn more about the two types of experiments, see Organize training runs with MLflow experiments.

:::

Changing these permissions also modifies the permissions on the notebook that corresponds to the experiment.

Ability

NO PERMISSIONS

CAN READ

CAN RUN

CAN EDIT

CAN MANAGE

View notebook

x

x

x

x

Comment on notebook

x

x

x

x

Attach/detach notebook to compute

x

x

x

Run commands in the notebook

x

x

x

Edit notebook

x

x

Modify permissions

x

Ability

NO PERMISSIONS

CAN READ

CAN EDIT

CAN MANAGE

View experiment

x

x

x

Log runs to the experiment

x

x

Edit the experiment

x

x

Delete the experiment

x

Modify permissions

x

This table describes how to control access to registered models in workspaces that are not enabled for Unity Catalog. If your workspace is enabled for Unity Catalog, use Unity Catalog privileges instead.

Ability

NO PERMISSIONS

CAN READ

CAN EDIT

CAN MANAGE STAGING VERSIONS

CAN MANAGE PRODUCTION VERSIONS

CAN MANAGE

View model details, versions, stage transition requests, activities, and artifact download URIs

x

x

x

x

x

Request a model version stage transition

x

x

x

x

x

Add a version to a model

x

x

x

x

Update model and version description

x

x

x

x

Add or edit tags

x

x

x

x

Transition model version between stages

x

x

x

Approve a transition request

x

x

x

Cancel a transition request

x

Rename model

x

Modify permissions

x

Delete model and model versions

x

Ability

NO PERMISSIONS

CAN VIEW

CAN RUN

CAN EDIT

CAN MANAGE

View cells

x

x

x

x

Comment

x

x

x

x

Run using %run or notebook workflows

x

x

x

x

Attach and detach notebooks

x

x

x

Run commands

x

x

x

Edit cells

x

x

Modify permissions

x

note

The workspace UI refers to view-only access as CAN VIEW, while the Permissions API uses CAN READ to represent the same level of access.

Ability

NO PERMISSIONS

CAN ATTACH TO

CAN MANAGE

Attach cluster to pool

x

x

Delete pool

x

Edit pool

x

Modify permissions

x

Ability

NO PERMISSIONS

CAN VIEW

CAN RUN

CAN EDIT

CAN MANAGE

View own queries

x

x

x

x

See in query list

x

x

x

x

View query text

x

x

x

x

View query result

x

x

x

x

Refresh query result (or choose different parameters)

x

x

x

Include the query in a dashboard

x

x

x

Edit query text

x

x

Change SQL warehouse or data source

x

Modify permissions

x

Delete query

x

Ability

READ

WRITE

MANAGE

Read the secret scope

x

x

x

List secrets in the scope

x

x

x

Write to the secret scope

x

x

Modify permissions

x

Ability

NO PERMISSIONS

CAN VIEW

CAN QUERY

CAN MANAGE

Get endpoint

x

x

x

List endpoint

x

x

x

Query endpoint

x

x

Update endpoint config

x

Delete endpoint

x

Modify permissions

x

Ability

NO PERMISSIONS

CAN VIEW

CAN MONITOR

CAN USE

IS OWNER

CAN MANAGE

Start the warehouse

x

x

x

x

View warehouse details

x

x

x

x

x

View warehouse queries

x

x

x

x

Run queries

x

x

x

x

View warehouse monitoring tab

x

x

x

x

Stop the warehouse

x

x

Delete the warehouse

x

x

Edit the warehouse

x

x

Modify permissions

x

x

Ability

NO PERMISSIONS

CAN CREATE

CAN USE

CAN MANAGE

Get endpoint

x

x

x

List endpoints

x

x

x

Create endpoint

x

x

x

Use endpoint (create index)

x

x

Delete endpoint

x

Modify permissions

x

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4