vault static secret version replacing behavior issue

[nia-potato]

lets say i would like the vso to push vault secrets latest 3 version to the cluster.

we currently have a version parameter and we can bump version:1 -> 2 and change the destination k8s secrets name that will be created. however it seems like we cannot use 3 vault static secret configs each referencing the same vault secret but with different versions and different destination names. note the purpose of this is just to keep the latest 3 versions of the same secret available for the pod to injest, thus i am open to any workarounds.

Expected behavior if the vault secret is

version1
secret
key: v1secretvalue
version2
secret
key: v2secretvalue
version3
secret
key: v3secretvalue

we then create 3 different vss configs

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: secret
  namespace: default
spec:
  destination:
    create: true
    name: secretv1
  hmacSecretData: true
  version: 1
  mount: secret
  path: test
  refreshAfter: 5s
  type: kv-v2

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
name: secret
namespace: default
spec:
destination:
  create: true
  name: secretv2
hmacSecretData: true
version: 2
mount: secret
path: test
refreshAfter: 5s
type: kv-v2

3rd is the same as the example above just with higher version and

the current behavior is: vso will just replace the existing secret instead of create a new destination secret based on the new version.

the expected behavior is: creating three secrets that is sourced from the same vault secret but because the version and destination name is different, it will create three secrets.

[benashz]

@nia-potato the destinations would need to be distinct between all VSS resources. I believe, VSO will not allow the 3rd instance since it is owned by the second, assuming the order of creation/reconciliation is 1-3.

[nia-potato]

@benashz thanks for the explanation,

If it is by design, would the only way to keep the last three versions of a secret to be create 3 distinct secrets instead of relying on the version parameter with one secret?

[benashz]

@benashz thanks for the explanation,

If it is by design, would the only way to keep the last three versions of a secret to be create 3 distinct secrets instead of relying on the version parameter with one secret?

Yes, you would need to create three distinct VaultStaticSecret (VSS) CRs. If I understand your use-case correctly. At some point in the future we may add support specifying multiple Paths and Destinations, but for now it's 1:1 Vault Secret -> K8s Secret.

[nia-potato]

Hey @benashz thanks for the update,

I think i may have not explained the use-case clearly, the gist of it is:

We need specific versions for latest 3. Can there be some support for denoting versions as latest, 2nd latest and 3rd latest and so on

[nia-potato]

@benashz would this be possible to implement with the current version logic?

[nia-potato]

hey @benashz any updates on this?

[nia-potato]

hey @benashz apologies for the ping again, but is this feature on the roadmap at all?

[benashz]

Hey @nia-potato - I am going to bring it up my team's next sync. I will keep you posted.