Allow NotebookUtils getSecret() to authenticate with Workspace Identity

Current behavior

In Microsoft Fabric, notebookutils.credentials.getSecret() authenticates against Azure Key Vault using the identity of the user who executes the notebook.

This behavior applies not only to interactive notebook execution but also to pipeline and scheduled executions in our environment.

Problem

Many enterprise environments separate responsibilities across multiple teams:

- Fabric administrators

- Azure administrators

- Entra ID administrators

Because getSecret() uses the executing user's identity, every Fabric notebook developer and operator must be granted Azure Key Vault permissions individually.

This creates significant operational overhead and makes centralized credential management difficult.

We have already enabled Workspace Identity and assigned the required Azure Key Vault permissions to it. However, notebookutils.credentials.getSecret() still authenticates using the user identity instead of the Workspace Identity.

As a result, Workspace Identity cannot currently be used as a central security boundary for Key Vault access in Fabric notebooks.

Requested enhancement

Please provide an option for notebookutils.credentials.getSecret() to authenticate using Workspace Identity instead of the executing user identity.

Example:

notebookutils.credentials.getSecret(

vaultUrl,

secretName,

authMode="WorkspaceIdentity"

)

or

Provide a workspace-level setting that enables Workspace Identity as the authentication context for Azure Key Vault access.

Benefits

- Centralized permission management

- No need to grant Key Vault access to every developer individually

- Better alignment with Workspace Identity governance model

- Improved enterprise security and maintainability

- Easier migration from hardcoded secrets to Azure Key Vault

This capability would significantly improve real-world enterprise adoption of Azure Key Vault within Microsoft Fabric.

We verified that Azure Key Vault access succeeds when permissions are assigned directly to the executing user, but fails when only Workspace Identity is granted access. This confirms that Key Vault access is currently evaluated using the executing user's identity rather than the Workspace Identity.