Rotate Credentials button in Static Role in VDS doesn't work for pods No rolling updates.

[toasahi]

Describe the bug The "Rotate credentials" button in the image changes the DataBase password, but not the pod environment variable (Secret). You will not be able to connect. The reason is obvious: the values of "rotationPeriod" and "rotationSchedule" in the VaultStaticCredsMetaData are not changed from the values when VaultDynamicSecrets is applied. Therefore, the pod does not perform a rolling update when the "Rotate credentials" button is pressed. This will cause a big problem in the future.

To Reproduce Steps to reproduce the behavior:

1. Enable database engine for postgres
2. Create static role
3. Apply the CRD of VSO.
4. Specify Deployment to be rotated for VDS
5. Press Rotate credential
6. Pods don't do rolling updates.

Application deployment:

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultDynamicSecret
metadata:
  name: vso-db-demo
  namespace: default
spec:
  allowStaticCreds: true
  # Mount path of the secrets backend
  mount: db/postgres

  # Path to the secret
  path: static-creds/postgres-role

  # Where to store the secrets, end user will create the secret
  destination:
    create: true
    name: db-secret

  # Restart these pods when secrets rotated
  rolloutRestartTargets:
  - kind: Deployment
    name: postgres

  # Name of the CRD to authenticate to Vault
  vaultAuthRef: vault-auth

Expected behavior VDS(StaticRole) uses a single User, so when the RotateCredentials button is pressed, the Pod should do a rolling update and the Secret should be rewritten.

Environment Kubernetes version: EKS vault: 1.15.1 vault-secrets-operator version: 0.4.0 postgres: 16.1.0

[benashz]

Hi @toasahi, currently, VSO does not support the use-case described in this issue, rather it relies on the interval set from the last sync. We plan to extend VSO to support Vault's notification system to reconcile the sort of of event that you describe here. Stay tuned.

Thanks,

Ben

[toasahi]

Hi @benashz ,I am very excited about that feature.I look forward to future upgrades.

Thanks,

Asahi

[Floppy012]

In the meantime: Would it be an option to have a flag that lets us force the refreshAfter period to take precedence over the lease time? Maybe even compare the last_vault_rotation with the one currently stored in the secret to detect whether a restart needs to happen.