Skip to main content

External secrets and certificates from Key Vault

Feature RequestsOpenTofu

Today, we have stack specific secrets that live in Azure Key Vault. To use them in Spacelift, we end up duplicating them into a Spacelift context or stack environment variables, so we have to maintain the same value both in Key Vault and in Spacelift. That creates extra work, increases the chance of drift, and makes rotation harder.

What I would like is a native way in Spacelift to reference an external secret store, starting with Azure Key Vault. For example, instead of pasting the value into a context, I want to be able to define something like “this variable comes from Key Vault secret X” and have Spacelift fetch it at runtime using the stack’s identity, service principal, or managed identity.

This is similar to how Azure DevOps variable groups can pull from Key Vault, if the identity has access, the secret becomes available as a variable during the run.

Status: ⬆️ Gathering votes4 comments

Log in to comment and vote

Comments4

  • Black Breeze

    •

    Mar 18

    Hey @Kenneth Hømlund Pedersen , thanks for raising this! Before we jump into designing this as part of Spacelift, I want to understand a few things?

    Are you perhaps using this in Terraform or OpenTofu? If so, have you considered using the `key_vault_secret` data source to access the value directly from declarative code?

    • Chocolate Sand

      •

      Mar 18

      I fully understand the key_vault_secret data source part however the idea is to centalize the solution like Variable Groups do in Azure DevOps. One place to maintain secret across multiple stacks. An example is that our Pulumi Username and Password is stored in a KeyVault in Azure. My Pulumi stack cannot run without the Username and Password. If updated then I have to manually copy the info from KeyVault to a Context to share across stacks. I would like to skip the manual step and have the Context connect directly to my PAM system which in this case is KeyVault.

      I do see the point in the data source however when you have multiple stacks accessing KeyVault in one Azure Tenant and doing apply in another Azure Tenant then the implementation because complex. Sure you can create a module that can handle it but still not ideal and flexible.