Skip to content
This repository has been archived by the owner on Nov 20, 2024. It is now read-only.

Support for secrets from Azure KeyVault (and potentially other secret management backends) #140

Open
OlegGorj opened this issue May 6, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@OlegGorj
Copy link

OlegGorj commented May 6, 2022

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

At this time, the only possibility to manage secrets as via K8s secrets and referenced in CRD.
We're looking to expand the secrets management capabilities to include reading secrets from Azure KeyVaults.

Potential Terraform Configuration

The proposed change could take a form as part of CRD manifest as the following:

---
apiVersion: app.terraform.io/v1alpha1
kind: Workspace
metadata:
  name: salutations
  azurekeyvault: my-key-vault.vault.azure.net   <--- here, specify the name of KV
spec:
  organization: hashicorp-team-demo
  module:
    source: "git::https://github.com/mygit/queues.git"
  variables:
    - key: application
      value: azurekeyvault@my-secret    <-- here, reference KV and secret name
      sensitive: true
      environmentVariable: false

Variable behaviour goes as:

  1. if value not specified as part of the block - usual route: read secret's value from k8s secret
  2. if value specified as part of the block (i.e. value: azurekeyvault@my-secret ) parse it and pull the secret from specified secrets back-end, in this case azurekeyvault.
    This could be expanded further to support multiple back-ends such as AWS KMS, HC Vault, etc.

References

n/a

@OlegGorj OlegGorj added the enhancement New feature or request label May 6, 2022
@thereallukl
Copy link

@OlegGorj please take a look at https://secrets-store-csi-driver.sigs.k8s.io/ I believe it solves your exact problem.

@F21
Copy link

F21 commented Nov 25, 2022

I would also like to see this with support for Vault, having spent the last day or so trying to get this working in a POC with the Vault CSI driver.

Here's what I want to do:

  • Keep all secrets in Vault
  • Secrets leased by Vault should be ephemeral and should expire
  • Secrets should be renewed and automatically updated in the workspace variables when renewed
  • Terraform cloud runs for each service in the kubernetes cluster should trigger via vcs

I tried the following:

  • Set up vault with kubernetes auth and roles for retrieving a secret
  • Set up Vault CSI and the CSI driver
  • Create a Secret Provider Class CRD to read secrets from Vault and sync to Kubernetes secrets

Problem:

  • As the Terraform Cloud workspace is not a pod, it does not have a service account to get secrets from the Vault CSI provider. One might argue that since TFC workspaces are tightly coupled to a service, there will be a pod. However, since the pod needs to mount the Secret Provider Class CRD and it might not need to access the secrets in the Secret Provide Class CRD at all, it can create confusion for future maintainers.
  • Since Kubernetes auth for Vault is tightly coupled to service accounts, it's not clear how this can really be done. Not sure how auth against other Vaults (Azure, etc) work, but perhaps there should be an extra field in the Workspace CRD to link a certain service account to a certain workspace.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants