Is your feature request related to a problem? Please describe.
In our current setup, our K8s platform customers use https://github.com/postfinance/vault-kubernetes to sync Secrets from Vault OSS into their desired Kubernetes namespace.
Our Vault is fully configured via Terraform. The k8s integration is done via Kubernetes Auth method on namespace basis (a Vault role per K8s namespace). In detail, we have this structure:
1 vault_kubernetes_auth_backend_config per cluster
N vault_policy per cluster (1 per namespace)
N vault_kubernetes_auth_backend_role per cluster (1 per namespace)
Describe the solution you'd like
It would be nice to share both
the vault default Connection
the vault default Auth (Kubernetes Auth)
with all customer namespaces, so they only need to define the VaultStaticSecret etc. :
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
name: default
namespace: vault-secrets-operator # <-- sits in the VSO namespace
spec:
method: kubernetes # same as tool from PF
mount: {{ printf "k8s-%s" .Values.clusterName }}
kubernetes:
role: vault-sync-vso
serviceAccount: vault-sync-vso
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
name: default
namespace: vault-secrets-operator # <-- sits in the VSO namespace
spec:
address: https://vault.example.com
caCertSecretRef: vault-ca
Describe alternatives you've considered
Only sharing the kind: VaultConnection with all namespaces and let our platform customers define the kind: VaultAuth in each namespace.
Additional context
I did a short PoC without spending too much time on the golang code which worked:
Is your feature request related to a problem? Please describe. In our current setup, our K8s platform customers use https://github.com/postfinance/vault-kubernetes to sync Secrets from Vault OSS into their desired Kubernetes namespace.
Our Vault is fully configured via Terraform. The k8s integration is done via Kubernetes Auth method on namespace basis (a Vault role per K8s namespace). In detail, we have this structure:
This module then installs multiple config resources inside Vault:
So in practice we have:
Describe the solution you'd like It would be nice to share both
with all customer namespaces, so they only need to define the
VaultStaticSecret
etc. :Describe alternatives you've considered Only sharing the
kind: VaultConnection
with all namespaces and let our platform customers define thekind: VaultAuth
in each namespace.Additional context
I did a short PoC without spending too much time on the golang code which worked:
Is this a valable approach? If so, I could invest some more time to make it configurable.
Maybe somehow related:
274