Fabric Key Vault Item (Native, fully SaaS Vault offering within a Tenant or Workspace)

[sean_ms]

Promoting the idea for Microsoft Fabric to develop a native SaaS Key Vault item. Currently, there are plans and limited existing integration with PaaS Azure Key Vault, however this is promoting a Hybrid architecture. To fully realize a SaaS workload, we need a Fabric Native item to allow for the secure storage and retrieval (native integration with other items, Pipelines, Notebooks,ect.) of Secrets and Certificates.

[mdjouallah1]

this is literally my last big wish in Fabric for my use case

[AlexPowers]

Sean is incredibly knowledgeable - he gets my [Voted] thumbs up.

[SJCuthbertson]

I've had a ticket open with our corporate IT team for 3.5 months now (and it's not even been assigned to someone yet), asking for an Azure Key Vault to be created for a few API secrets we need within Fabric. Having a KV within Fabric itself would be a game changer for me / my org.

[Koen_Verbeeck]

This would be a gamechanger.

[MarcoBB]

yes please, i really don't have a good way to integrate the accesses to all my external data sources. although i have access to azure key vaults, this still does not solve all the needs (by far), such as identity of the secret user, etc.

[dsandberg]

I've been hammerin' away at trying to get a Notebook, which is running in an environment with a custom Python library. The custom library uses an Azure Key Vault for managing access to secrets (connection strings, credentials, etc). But, when I import the library and try using methods in my custom library, I hit "DefaultAzureCredential" errors. Keyvault in Azure seems like it should have been part of the Fabric GA rollout?

[SDHorita]

Right now, if you have to put the service principal secret in the code in order to authenticate against a key vault anyways from a notebook, that is only marginally better than just having a plain text API key in the code. Having it as an object that can be created in a specific workspace would be a lot better. For me, it doesn't even have to be the same as a key vault. With the new variable library object, something similar to that, but set up for hidden information, or where you can mark some variable rows as secret would be really helpful.

[kwitcom2]

This proposal would drive material value for large-scale enterprise deployments. Our organization manages more than 1.3 million active Fabric workspaces globally. Most of our users are citizen developers with no direct Azure access, and only a small set of administrative accounts can interact with Azure Key Vault or configure private endpoints. Even when users have contributor rights in Fabric, they can’t operationalize an Azure Key Vault without elevated Azure permissions, which creates friction and support overhead. Microsoft has been moving core capabilities directly into the Fabric workspace. Adding a native vault service aligns with that direction and removes the dependency on external Azure resources. It gives governed, credential-secure patterns to the people who actually build solutions, without requiring them to navigate Azure RBAC or networking constraints. A native Fabric vault would streamline onboarding, reduce operational bottlenecks, and improve compliance at enterprise scale. This is a high-impact addition for any organization running Fabric as a centralized analytics platform.

[CoulterJames2]

This is a great idea - the current AKV integration is clunky and has a lot of limitations e.g. does not support data sources that depend on a Data Gateway. This would solve the problem in an instant as well as keeping corporate cybersecurity people happy.