You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on integrating HashiCorp Vault into our FluxCD using SOPS for secret management. We use Vault as a Service which provides us with a specific namespace for our operations. Unfortunately, it seems that SOPS currently does not support Vault's namespace integration into secret's metadata.
I did some research and found this discussion on fluxcd repo. It seems that kustomize controller (that is responsible for secret decryption on FluxCD part) gets all the information about Vault from the secret's metadata. It becomes a problem, because that does not allow to properly request for the transit key on Vault to decrypt the secret.
Given the fact that already there was an interest in this feature and growing adoption of both Vault and GitOps practices, I think this feature could highly benefit the community.
Proposed Solution:
I propose adding a field to the secret's metadata managed by SOPS that specifies the Vault namespace.
Impact:
This feature would greatly facilitate secret management for organizations that make use of Vault's multitenancy, making it easier to maintain secure and efficient GitOps pipelines.
Thank you so much,
Sanzhar
The text was updated successfully, but these errors were encountered:
Hello!
I am working on integrating HashiCorp Vault into our FluxCD using SOPS for secret management. We use Vault as a Service which provides us with a specific namespace for our operations. Unfortunately, it seems that SOPS currently does not support Vault's namespace integration into secret's metadata.
I did some research and found this discussion on fluxcd repo. It seems that kustomize controller (that is responsible for secret decryption on FluxCD part) gets all the information about Vault from the secret's metadata. It becomes a problem, because that does not allow to properly request for the transit key on Vault to decrypt the secret.
Given the fact that already there was an interest in this feature and growing adoption of both Vault and GitOps practices, I think this feature could highly benefit the community.
Proposed Solution:
I propose adding a field to the secret's metadata managed by SOPS that specifies the Vault namespace.
Impact:
This feature would greatly facilitate secret management for organizations that make use of Vault's multitenancy, making it easier to maintain secure and efficient GitOps pipelines.
Thank you so much,
Sanzhar
The text was updated successfully, but these errors were encountered: