Why one secrets service across Azure and other clouds is an Azure Key Vault alternative question
Many organizations with workloads in Azure, other clouds and on-premises data centers end up with a Key Vault per subscription, each with its own access policies, role assignments and network rules. In that situation, one self-hosted OpenBao or Infisical service with cloud auth methods can replace most of the per-subscription vaults, while Key Vault remains the fit for Azure services that require customer-managed keys. This page covers that constraint: how a single secrets service changes the way access is granted across environments, and which Azure dependencies stay in Key Vault. It does not compare features in general, which is covered in the sibling comparison pages.
The cost of the current setup is mostly in duplication. Each vault needs its own access model, its own audit trail and its own review cycle, and the same application identity often has to be granted access in several places. Before deciding, list every vault with its subscription, region, owning team and the Azure services that read from it. Then list the non-Azure workloads that also read secrets and how they authenticate today. Those two lists show whether a central service would reduce work or simply add another system to operate.
A central service also changes who is responsible for availability. OpenBao and Infisical can authenticate workloads through cloud identities such as Azure, AWS, GCP and OIDC, but the organization then runs the servers, storage, backups and upgrades. Confirm with your platform team whether the Azure services you depend on accept secrets from an external store, and which ones bind to Key Vault directly. Those services, especially those that need customer-managed keys, should stay in Key Vault, and the design should keep them out of the migration scope from the start.
What a multi-cloud secrets design must satisfy
A single secrets service spanning Azure, other clouds and on-premises sites has to answer to several teams and several audit regimes at once. The six requirements below connect identity, audit, policy, availability and the Azure services that still depend on Key Vault.
Workload identity instead of shared secrets
Each workload should prove who it is with the identity its own platform issues, such as a Kubernetes service account, an AWS, GCP or Azure identity, or an OIDC token, rather than presenting a long-lived secret that gets copied between environments. OpenBao documents Kubernetes, JWT/OIDC, TLS certificate and AppRole methods, and Infisical lists Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth. Check which method each workload class can use, and where a fallback such as AppRole is still needed for servers.
One audit trail across clouds
When every cloud writes access logs to a different service, incident response has to join several incomplete records. Route all secret reads, writes and token events from both products into one log pipeline that your SIEM can query. Confirm with the vendor which audit devices each product supports and how log integrity is protected, since this depends on the deployment you choose.
Consistent access policy
Teams in Azure, AWS and on-premises should be governed by the same rules for who can read a secret, from which identity and for how long. Model this as one set of policies tied to identity attributes and namespaces, rather than separate role assignments in each subscription. Namespaces are documented for OpenBao, so verify how they map to your business units before you migrate policies.
High availability across sites
A central secrets service becomes a dependency for every workload, so a single-site outage stops deployments everywhere. OpenBao runs one active node holding a lock in the data store, with standbys that forward or redirect requests, and Integrated storage (Raft) and PostgreSQL are its officially supported HA backends. Decide where the nodes and the backing store sit across sites, and test failover before cutover.
Read scaling for many consumers
Many workloads reading secrets at the same time can concentrate load on the active node. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Ask your team to size read traffic per site and confirm that the chosen storage backend and version support the read pattern your applications use.
Azure services that need keys in Key Vault
Some Azure services, such as those that depend on customer-managed keys, can only use keys held in Key Vault or Managed HSM. Keep those keys where the Azure service expects them and move only the application secrets and non-Azure workloads to the self-hosted service. List each dependency before scoping the migration, and confirm the current customer-managed key requirements with Microsoft for each service you run.
Where Azure Key Vault still meets the need and where it does not
Azure Key Vault remains the natural home for Azure services that need customer-managed keys, because those services are wired to Key Vault and Managed HSM as their key source. Key Vault is Microsoft's managed service for secrets, keys and certificates, billed per operation, per key and per certificate renewal. Before changing anything, list every Azure service in scope and check, service by service, whether it accepts a customer-managed key from a Key Vault or Managed HSM, and whether it can use an external key store at all. Confirm the answer with Microsoft's current documentation for each service, since support differs between storage, database, disk and messaging services and can change over time.
The harder decision is the vault layout. Key Vault is scoped per subscription and region, so a hybrid estate often ends up with one vault per subscription, plus separate stores in AWS, Google Cloud and on-premises systems. Each of those stores has its own access policies, audit trail and rotation process. A self-hosted OpenBao or Infisical service can hold application secrets for all of these environments behind a single access model, using cloud auth methods so that workloads authenticate with the identity they already have. The trade-off is that you then operate the secrets platform, its availability and its backups yourself, and your own design must replace the regional redundancy Key Vault gives you by default.
Keep Key Vault where a Microsoft service requires it, and move the rest only after you have mapped dependencies. Ask Microsoft which services in your estate will fail or lose encryption capabilities if their keys move, and which of your workloads read secrets from Key Vault through the SDK or managed identity. For a multi-cloud estate, a workable split is often Key Vault for keys that Azure services consume directly and OpenBao or Infisical for application secrets used across clouds. Document that split as a decision record, because it determines which team owns each store, which backups you must test and which audit logs your compliance assessor will ask for.
Which open-source option fits a hybrid secrets service
This table compares OpenBao and Infisical for one secrets service spanning Azure, other clouds and on-premises systems. Read each row as a decision point: auth methods, storage and high availability, licensing and which features sit behind Infisical's enterprise license. The main takeaway is that both can serve multiple clouds, but the auth, storage and licensing details decide which fits your operating model.
| Decision point | OpenBao | Infisical |
|---|---|---|
| Cloud and workload auth | AppRole, JWT/OIDC, Kubernetes and TLS certificate auth; confirm which cloud identity flows fit each Azure, AWS and GCP workload | Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities; confirm Azure and on-premises coverage in your version |
| Human and developer login | Userpass recommended for developer machines; OIDC via JWT auth; confirm SSO integration with your identity provider | SSO and some gateway features need enterprise licensing; confirm which features your license covers |
| Storage backend | Integrated Raft, PostgreSQL, PebbleDB or in-memory; PostgreSQL is described as easier to operate safely than Raft | PostgreSQL and Redis are bundled in the official Helm chart; confirm the supported external database layout for production |
| High availability | Active node with a lock in the data store and standby nodes; Raft and PostgreSQL are the officially supported HA backends | Confirm the HA topology for your chosen deployment method (Docker Compose, Helm or Linux packages) before sizing regions |
| Multi-site reads | Since 2.5.0, Raft standbys serve read-only operations; v2.7.0 extended this to PostgreSQL | Confirm read scaling and replication behavior with the vendor for multi-region designs |
| License for core product | MPL-2.0 for the repository, governed by a community under the Linux Foundation's OpenSSF | MIT Expat except content in any ee directory, which uses the separate ee license |
| Enterprise feature gating | Community project; confirm which features your chosen support arrangement covers | SSO and gateways require enterprise licensing per the self-hosting documentation; check the license before designing around them |
| Gaps to confirm | Confirm Azure-specific secret engines and Key Vault style key operations, which OpenBao does not replicate directly | Confirm HSM-backed key protection and customer-managed key support for Azure services, which Key Vault provides natively |
How to deploy one secrets service across clouds
This sequence turns a set of per-subscription Key Vaults into one self-hosted secrets service that Azure, other clouds and on-premises workloads reach through their own identity providers, with clear decisions on which Key Vault instances stay.
Choose the platform and hosting location
The platform team, with security and the Azure subscription owners, decides between OpenBao and Infisical based on whether the main consumers are infrastructure and service workloads or developers working through projects and environments. They also choose where the service runs: a dedicated subscription or account, a data center, or a neutral location that all clouds can reach with low latency. Confirm the chosen platform's license terms with your legal team before commitment, since OpenBao is MPL 2.0 and Infisical's core is MIT with enterprise features under a separate ee license. The step is done when a written decision record names the platform, the hosting location and the owning team.
Build highly available storage
The infrastructure team provisions the storage backend for the cluster. OpenBao's documented HA options are integrated storage (Raft) and PostgreSQL, and its storage documentation describes PostgreSQL as easier to operate safely than Raft. Choose one, place nodes across failure domains, and test leader failover before any secret is stored. Confirm the exact node count and backup approach against the current OpenBao HA documentation and your own resilience requirements. The step is done when a planned failover completes without loss of service and the backup restore has been tested at least once.
Install the service with its Helm chart
The platform engineers install the service on Kubernetes using the OpenBao Helm chart, which requires Helm 3.6 or later, or Infisical's official Helm chart, which bundles PostgreSQL and Redis unless you point it at managed instances. Pin chart and application versions, store values in version control, and review the TLS configuration for internal and external endpoints. Confirm the cluster placement and ingress path that every cloud will use. The step is done when the service answers health checks on every node and the initialization or bootstrap steps are recorded in the team's runbook.
Configure cloud auth methods per environment
Enable an auth method for each cloud and environment, such as the JWT/OIDC method for Azure workload identities, the Kubernetes method for clusters, and the AWS, GCP or Azure methods of Infisical where they fit. Map each method to least-privilege policies or roles so that a workload in one subscription can read only its own paths. Confirm the exact method names and claim mappings against the current auth documentation for your chosen platform. The step is done when a test workload in each cloud authenticates, reads one permitted secret and is denied one secret outside its scope.
Confirm network paths and DNS between clouds
The network team verifies that each cloud can reach the service endpoint over a permitted path, such as private connectivity or an approved public route with mutual TLS, and that DNS names resolve consistently from Azure, other clouds and on-premises networks. Firewall rules, private DNS zones and certificate subject names all need review. These details depend on your own environment and must be confirmed there rather than assumed. The step is done when each cloud's test workload resolves the service name, connects over the intended path and logs the connection in the security monitoring tool.
Migrate workloads one subscription at a time
Application teams move workloads group by group, starting with a low-impact subscription. For each application they replace the Key Vault reference with a call to the new service, copy secret values through the API where the owner has authority to do so, and keep the old value readable until the new path is proven. Rotate credentials that were exposed to the migration process. The step is done when the application runs on the new path in production for an agreed observation period and its Key Vault references are removed.
Decide which Key Vault instances remain
The architecture group lists every Key Vault and classifies it. Vaults that hold keys required by Azure services with customer-managed key support, or that feed services you have not yet moved, stay in place under documented ownership. Vaults whose consumers have all moved are scheduled for decommissioning after their soft-delete retention is planned. Record the reason for each retained vault. The step is done when the inventory shows every remaining Key Vault with an owner, a retention reason and a review date.
Questions buyers ask before replacing Key Vault across clouds
What does a multi-cloud secrets migration cost, and what drives it?
The cost splits into one-time work and recurring operations. One-time work covers architecture, deploying OpenBao or Infisical in your environment, configuring cloud auth methods for each Azure subscription, AWS account or cluster, migrating secrets and rewriting application access. Recurring costs cover the servers or Kubernetes capacity, the storage backend, backups, upgrades, monitoring and the people who respond to incidents. The main cost drivers are the number of cloud accounts and subscriptions to trust, the number of workloads that read secrets, whether you need high availability across sites, and whether you keep an HSM for key protection. Key Vault bills per operation, key and renewal, so your current invoice is the baseline to compare against. Ask any provider for a written scope that lists each component separately, with who pays for what and which items recur.
How long does a rollout take when there are many workloads?
The timeline depends mainly on how many workloads and cloud environments must move, and on how many of them read secrets in unusual ways. A practical rollout usually starts with one platform and a small set of low-risk workloads, then adds clouds and clusters in waves, so each wave has a rollback path. Workloads that use managed identity or hard-coded connection strings take longer than those that already read secrets through a common library. Because no researched timeline is available for this scope, ask for a phased plan in the written scope, with one milestone per wave, the workloads in each wave and the acceptance criteria for moving to the next one.
What must our team provide during the engagement?
Your team provides access and decisions, and the engagement depends on them. You need administrative access to the Azure subscriptions, AWS accounts, GCP projects and clusters that will authenticate to the new service, plus the network paths between them and the hosting environment. Someone must own identity mapping, meaning which Entra ID, Kubernetes service account or cloud role maps to which policy. You also need an on-call rota that covers the secrets service, since it becomes a dependency for every workload that starts up. Ask the provider to list these inputs, the named people for each, and the change windows in the written scope.
Can our own engineers run OpenBao or Infisical without outside help?
Yes, many teams operate these platforms themselves, but the decision depends on existing skills and on the risk you accept. OpenBao is a Vault fork, and its migration guide describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, tested only against that version. Infisical offers Docker, Docker Compose, a Helm chart with bundled PostgreSQL and Redis, Linux packages and AWS or GCP reference deployments. Running either service well needs experience with unsealing or key handling, high availability, backups and upgrades. Ask for a written split of responsibilities so you know which tasks stay with your team and which are covered by a fixed-scope project or a retainer.
Do we have to remove Azure Key Vault completely?
No, most organizations keep Key Vault for the services that depend on it. A common pattern is to move application secrets and dynamic credentials to one OpenBao or Infisical service that every cloud can reach, while leaving keys that Azure services need under customer-managed control in Key Vault. Check each Azure service's documentation for its customer-managed key requirements before you decide what moves. Key Vault can also stay in place during a transition, so workloads can switch in waves. Ask the provider to produce a service inventory that marks each consumer as moved, kept or dual-running.
How does Infisical's license affect the enterprise features we need?
Infisical's repository is under the MIT Expat license, but content in any ee directory is under a separate license in ee/LICENSE. Infisical's self-hosting documentation says that enterprise features such as SSO or gateways require enterprise licensing. Before you choose Infisical for multi-cloud access, confirm which features your design depends on, such as SSO for operators or gateways into private networks, and whether they fall under the enterprise license. Ask the vendor for the licensing terms in writing and check them against your legal team's review.
Which auth methods replace Azure managed identity for other clouds?
OpenBao documents AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens and username and password, and recommends AppRole for servers. Infisical supports Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. For Azure workloads, check whether the platform can validate the identity your workloads already present, and plan a separate path for AWS, GCP and on-premises systems. Confirm each mapping in a test environment before you change production.
What should we request in a written scope before signing?
Ask for a written scope that names each deliverable and its acceptance test. Include the platform version and deployment method, the storage backend and high availability design, the cloud auth methods per environment, the list of workloads in each wave, backup and restore testing, and the handover plan. Request a separate line for each recurring service, such as support or upgrades, and confirm whether the price covers licensing for any enterprise features. DeployOpen plans, implements, integrates, backs up and documents self-hosted platforms in your own infrastructure, and quotes follow from the written scope.
Evidence auditors and regulators ask for
A hybrid or multi-cloud secrets service concentrates access to credentials from several clouds into one place, so the evidence has to show who can reach which secrets and what they did with them. The cards below cover the records that connect an OpenBao or Infisical service to the Key Vault instances that remain in Azure. Independent auditors and regulators decide whether the evidence is sufficient for your scope.
Access policy exports per cloud identity
Export the policies and roles that bind each cloud identity to a path or project, from AWS, GCP, Azure, Kubernetes and OIDC, and keep them dated. Auditors will ask how an Azure managed identity or a Kubernetes service account maps to a named OpenBao policy or Infisical role, and whether any identity has broader reach than its workload needs. Confirm that every cloud auth mount has an owner and a review date.
Audit logs for secret reads
Keep the audit device output for every secret read, write and token issuance, and record where it is shipped and how long it is retained. Each application that still reads from Key Vault should have a comparable read trail on the new service during cutover. Check that log entries identify the cloud identity used, not only a shared service account, and that logs are protected from the teams whose access they record.
HA and backup test records
Keep dated results of failover tests for the active node, restores from snapshots or backups, and the unseal or key-recovery procedure exercised by the team. A single service that holds credentials for several clouds becomes a shared dependency, so a documented restore is the evidence that it can be recovered. Confirm the storage backend you chose and the HA design in writing before the first test.
Key custody records for HSM or KMS use
Where keys are protected by an HSM, a cloud KMS or Azure Key Vault Managed HSM, record who holds the unseal material or key-encryption keys, how they were generated, and how custody changes over time. Auditors will compare these records with the key ceremony and rotation logs. Confirm which keys stay in Azure for customer-managed key scenarios and which are held by the OpenBao or Infisical deployment.
Decisions on remaining Key Vault instances
Maintain a register that lists each Key Vault instance that stays in place, the Azure service that requires it, the owner and the reason it cannot move yet. The register should also record instances scheduled for retirement and the date each decision was reviewed. This gives auditors a clear boundary between the shared service and the Azure resources that depend on customer-managed keys. Confirm the register with the teams that own those services.
How DeployOpen designs a hybrid secrets service
DeployOpen approaches an Azure Key Vault replacement for hybrid and multi-cloud estates as a fixed-scope engagement. We map which workloads, subscriptions, clouds and on-premises systems read secrets today, then design one self-hosted secrets service inside your own infrastructure that those workloads can reach through their native identities.
How we scope
- We inventory every Key Vault, subscription and consuming workload that reads secrets, keys or certificates today.
- We agree the written scope with you, covering which secret types move, which stay in Key Vault and who operates each part.
- We confirm which cloud and on-premises identity sources, such as Entra ID, AWS, GCP or Kubernetes, each workload will authenticate with.
How we build
- We install OpenBao or Infisical in your environment with the storage backend and high availability design agreed in scope.
- We configure cloud auth methods, access policies and namespaces so each team reaches only the secrets it owns.
- We test failover, access denial, audit logging and revocation paths before any production workload is switched over.
How we hand over
- You receive architecture records, configuration as code, runbooks for unseal, backup and upgrades, and the access model.
- We document which Azure services still depend on customer-managed keys in Key Vault and how that boundary is maintained.
- We walk your platform and security teams through operating the service so ownership is clear after the engagement closes.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer, scoped in writing.
- We can prepare configuration, access and logging evidence for your compliance assessors, who make the formal determinations.
- Before each platform upgrade, we review release notes and test against your own configuration in a non-production copy.
