topic Can Run Notebook Permission in Data Governance

Can Run Notebook Permission

DeepeshDandwani — Thu, 09 Jul 2026 08:39:06 GMT

If a user has Can Run permission on a notebook, why are they still able to view the notebook's contents without having Can View permission?
Restricting visibility while allowing execution could be useful in scenarios where sensitive configuration details or logic are stored in a notebook and accessed by other notebooks using the %run command.

Re: Can Run Notebook Permission

balajij8 — Thu, 09 Jul 2026 09:54:25 GMT

Securing data pipelines by hiding sensitive information is a key topic in any platform. It is achieved using Databricks Secrets for runtime code configurations etc. Sensitive information storage is to be avoided completely in notebooks.

Can Run Inherently Granting View Access

In Databricks, the Can Run permission inherently includes the ability to view the notebook contents by design

When a user executes a notebook, visibility into that code is required for several critical reasons as below

Debugging and Troubleshooting - Users must be able to see error messages, stack traces and execution outputs to verify why a job succeeded or failed.
Understanding Execution Context - Users need to know exactly what logic is processing their data to validate behavior and ensure data integrity.
Preventing Black Box Pipelines - Allowing execution without visibility creates an environment where code is impossible to debug, audit or to understand. This creates operational bottlenecks in data workflows.

Hiding Configurations with Databricks Secrets

When you need to protect credentials, API keys or sensitive connection strings, the native and secure approach is to abstract them out of the notebook entirely using a Databricks Secret Scope. You store the sensitive values in a secure vault (AKS/AWS Secret Managers etc) rather than hardcoding them into a cell in the notebook. When you reference these secrets in your code using dbutils.secrets.get(), Databricks automatically redacts the actual values from the notebook outputs. Users can execute the notebook and run the necessary logic, but the plaintext secrets remain completely hidden from view even in the execution logs or display outputs.

For protecting sensitive business logic rather than just credentials, you can encapsulate that code inside Unity Catalog Functions & use RLS/CLS/ABAC (users granted relevant privileges without seeing the implementation) or run workflows as a Service Principal.

By separating your secure configurations (via Secrets) from your execution logic (the Notebook), you can maintain transparent, easily debuggable pipelines without compromising on security.

Re: Can Run Notebook Permission

AbhilashNagilla — Thu, 23 Jul 2026 17:19:08 GMT

This is by design: Can Run always includes viewing the cells.

Notebook access has a single view-only level (labeled CAN VIEW in the UI, CAN READ in the Permissions API) that sits below Can Run, and %run and notebook workflows execute at that view-only level. So anyone who can run the notebook can read it, and ACLs cannot grant execution while hiding the code.

To protect the sensitive parts, move them out of the notebook:

Put credentials in a secret scope and read them with dbutils.secrets.get(). Redaction is best effort (literal values only, and not applied to the Spark driver's stdout/stderr), so also limit who can run the notebook.
Move shared logic into a library or wheel, or a Unity Catalog function with EXECUTE granted, so callers use it without seeing the source.
Run the sensitive work through a job or service principal, so users trigger it without opening the notebook.