Users can access key vault secrets using notebookutils.credentials.getSecret. This is based purely on the user's access (or object owner's access, if the notebook is being run in a pipeline). In larger organizations, managing access at the individual level is not scalable. It would be preferable to associate key vault privileges with a service principal so that connections keep running if a particular user leaves the business.
The workspace identity is an obvious candidate to be given key vault permissions. While this is technically possible - we can add key vault privileges to a workspace identity's associated entra ID app service principal - the service principal's credentials are not used by the notebookutils.credentials.getSecret method. (At least based on my current understanding - this seems to be a known limitation if you read related posts in the Fabric user forums as of August 2025).
Please make it possible to access key vault secrets using workspace identities.
3 Comments
- It is crazy how many places in Fabric the workspace identity can NOT be used. For a service intended to support enterprises, this dependency on user identities is unacceptable.
sean_cochranResolver I
For anyone who liked this idea - there is now a workaround. Notebook connections can be used in a pipeline to force an SP's credentials to be used when making a key vault call. Not perfect, but it's something.
PeterDanielsAdvocate III
This would simplify AKV access so much. please, please, please
Recent ideas
Allow Power BI subscriptions to use a no-reply sender instead of the subscription owner's mailbox
Following the migration to the new email delivery platform, subscription emails now appear to come from the subscription owner. This generates large volumes of Out of Office replies, auto-replies, an...
