topic Can we Change the ownership of Databricks Managed Secret to SP in Azure Data Bricks? in Data Engineering

Can we Change the ownership of Databricks Managed Secret to SP in Azure Data Bricks?

Naveenkumar1811 — Thu, 13 Nov 2025 13:16:16 GMT

Hi Team,

Earlier we faced an Issue where the jar file(Created by a old employee) in workspace directory is used as library in the cluster which is run from a SP. Since the employee left the org and the id got removed even though the SP is part of ADMIN group we had issues in cluster start. Similarly we are doubting we could run similar issue if the secret created by a user and he left, which can cause issue?

Re: Can we Change the ownership of Databricks Managed Secret to SP in Azure Data Bricks?

Coffee77 — Thu, 13 Nov 2025 14:19:44 GMT

That's the reason by which I try to deploy most part of resources with service principal accounts while using Databricks Asset Bundles. Avoid human identities whenever possible because they can indeed go away...

I think you'll have to create another secret in the same or another scope trying to "read" the previous secret with an account with "manage" permissions. I'd say that is not possible with "read" permissions but you could try. Then, create new scope and/or secret with a "service principal" account and assign permissions to other users if needed. This wiill avoid at least same issue in future.

databricks secrets get-secret <scope-name> <key-name> | jq -r .value | base64 --decode

Re: Can we Change the ownership of Databricks Managed Secret to SP in Azure Data Bricks?

Naveenkumar1811 — Mon, 17 Nov 2025 13:43:35 GMT

We have multiple instance where the secrets are referred. so creating the secret with new name will cause code changes in multiple places. So as per your suggestion i should delete the existing secret and recreate the new one with Databricks CLI with SP pat token?

Re: Can we Change the ownership of Databricks Managed Secret to SP in Azure Data Bricks?

Coffee77 — Mon, 17 Nov 2025 14:14:41 GMT

I think there is no other way.

In any case, here is how I usually configure my (all-purpose and jobs compute) clusters to access secrets via environment variables so that you don't have to update all references if some similar issue arises again. The environment variables act as an abstraction between secrets and consumer code.