How should security teams govern secrets in Azure Databricks workloads?

Treat the notebook, workspace, and secret store as one access chain. Require identity-bound retrieval at runtime, avoid hardcoded values in code or configuration, and scope each workload to only the secrets it needs. Governance should cover secret ownership, rotation, and offboarding for the workload, not just storage location.

Why This Matters for Security Teams

Azure Databricks secrets are not just storage objects. They sit inside an execution path that includes the notebook, the workspace, the cluster runtime, and the identity used to fetch them. That means governance has to cover who can retrieve a secret, when it is retrieved, and whether the workload should still have access at all. Static values in code or config create long-lived exposure that survives notebook sharing, job reuse, and weak offboarding.

This is especially important because machine identities are already hard to inventory and audit. NHIMG’s Critical Gaps in Machine Identity Management report notes that 57% of organisations lack a complete inventory of their machine identities, which makes secret ownership and rotation difficult to enforce. The security problem is not limited to Databricks itself; it is the broader pattern of secrets sprawl, where credentials outlive the workload and are copied into places governance cannot see. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward least privilege, strong identity, and continuous control over machine access. In practice, many teams discover Databricks secret exposure only after a notebook is shared, a job is cloned, or a service principal is left active after the workload has moved on.

How It Works in Practice

Good Databricks secret governance starts by treating the workload as the unit of control. The secret store, the workspace, and the identity that runs the job should be linked by policy, not by convention. Instead of embedding API keys in notebooks or cluster configuration, teams should require runtime retrieval with identity-bound access. That means the job or cluster proves what it is, then receives only the specific secret it needs for that task.

Practically, this pattern works best when secrets are short-lived, scoped, and revocable. Static secrets are difficult to justify for autonomous or reused workloads because the blast radius extends far beyond the original task. Where possible, use workload identity and token exchange rather than copying credentials into the Databricks environment. The SPIFFE workload identity specification is useful here because it frames identity as a cryptographic proof of workload identity, not a shared secret. NHIMG’s Guide to SPIFFE and SPIRE is a helpful companion for teams designing that model.

• Assign each Databricks job or pipeline a distinct workload identity.
• Map each identity to the minimum secret set required for that workload.
• Fetch secrets at runtime, then expire access after task completion.
• Rotate secrets on a schedule tied to ownership, not just storage age.
• Remove access automatically when the notebook, job, or team offboards.

Governance also needs auditability. Security teams should be able to answer which workload used which secret, when, and for what purpose. NHIMG’s Guide to the Secret Sprawl Challenge shows why this matters across modern engineering estates: secrets leak into code, tickets, logs, and build systems faster than teams can clean them up. These controls tend to break down when multiple teams share one workspace or one service principal because attribution and revocation become ambiguous.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance access friction against the need to prevent silent credential reuse. That tradeoff is real in Databricks environments where notebooks are cloned, clusters are ephemeral, and data engineering teams move fast. Best practice is evolving, but there is no universal standard for whether every secret should be fully dynamic or whether some low-risk values can remain centrally managed with strong monitoring.

One common edge case is legacy notebooks that assume environment variables or hardcoded config are acceptable. Those workloads usually need refactoring rather than simple policy tightening. Another is shared clusters, where a single runtime identity can blur workload boundaries. In those environments, secret isolation often fails because the platform can no longer distinguish one job’s intent from another’s. Teams should also be careful not to equate secret storage with secret security. A secret placed in a managed store is still risky if every job in the workspace can retrieve it.

NHIMG’s Ultimate Guide to NHIs is a useful reference point for the difference between static and dynamic secrets, while the OWASP Non-Human Identity Top 10 reinforces why overprivileged, long-lived credentials remain a core failure mode. The most common mistake is treating secret retrieval as an application detail instead of a workload governance decision.

Related resources from NHI Mgmt Group

• How should teams govern secrets when workloads span multiple regions?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?