Almost every data team has a story about a password in the wrong place. It might be an API key pasted into a notebook "just to test something," or a connection string that made it into Git. Sometimes it's a shared credential that nobody dares rotate, because nobody is sure what would break.

Databricks now offers a cleaner answer: secrets stored directly in Unity Catalog.

What it is

A Unity Catalog secret is a sensitive value, such as an API key, a password or a token, stored inside a schema. It sits alongside your tables, volumes and functions and is governed by the same permission model. Before this, secrets lived in separate workspace-level scopes, which meant a second place to manage access and a second place to forget about.

How it works in practice

You create a secret once, in Catalog Explorer or through the REST API. Code then retrieves it at run time with a single call, dbutils.secrets.get, using the catalog, schema and key names. If someone tries to print the value in a notebook, Databricks shows [REDACTED] instead.

Access is controlled with dedicated privileges:

Because these privileges inherit from catalog and schema, you can set up access once and let it flow down.

The part I find most useful: using a secret without seeing it

Secrets can also be used inside Unity Catalog Python UDFs. The function declares which secrets it needs, and Databricks runs it with the function owner's permissions. A user can call the function, and get the result of an authenticated call or an encryption step, without ever holding the secret. Analysts get their answers and only the right people hold the credentials.

A small feature worth noticing: the Secrets tab

Open any schema in Catalog Explorer and you'll find a Secrets tab next to Tables, Volumes, Models and Functions. It lists every secret in that schema, who owns it and when it was created. It's a small detail, but it makes credentials visible in the same place as the data assets they support. Audits get easier, ownership is clear, and stale secrets are harder to overlook. You can also set expiration dates, which gives you a built-in nudge to rotate.

Rotation and audit

Rotating a secret is a one-place change: update the value and the next run picks it up, with no code edits. Secret activity also appears in your audit logs, so you can answer the question "who accessed this, and when?"

What to keep in mind

Like any feature, it has edges. You can't retrieve these secrets from init scripts, and SQL warehouses can only use them through UDFs that declare them. Reading a secret through the REST API returns the value unredacted, so Databricks recommends dbutils for retrieval. If your policy requires values to stay in Azure Key Vault, there is an option to back a schema with Key Vault, and your code stays the same.

The takeaway

Credentials are data-adjacent assets, and they deserve the same governance as the data itself. Putting secrets in Unity Catalog means fewer hidden passwords, clearer ownership and one permission model for everything. That's a good trade.