DatabaseSecretEngineConfig priviledged user's password from kubernetes secret not updating.

[vbouchaud]

I'm currently working in an environment where the priviledged database user's password I'm referencing in a DatabaseSecretEngineConfig is updated regularly using an ExternalSecret with a Generator. Database engine is postgresql and, if it matters to the issue at hand, it's provisioned on GCP CloudSQL through yaml resources too (kubernetes config connector). The priviledged user's password is correctly updated in the pg instance.

Contrary to what is written in the documentation for the DatabaseSecretEngineConfig, it seems vault-config-operator does not watch for changes in kubernetes secrets where user credentials are provided. I mean here that when the DatabaseSecretEngineConfig is first created, DatabaseSecretEngineRole are then working as intended. I'm able to create dynamic roles in the database without issue. After a while (after the priviledged account's password rotated), I get the following error:

	* unable to start transaction: failed to connect to `host=instance-postgres-1.foo.bar user=baz database=quux`: failed SASL auth (FATAL: password authentication failed for user "baz" (SQLSTATE 28P01))

This is the manifest I wrote to define a connexion (minus some later kustomization patches):

# ExternalSecret resources for reference (you can see the type basic-auth of the secret it will generate)
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: user
spec:
  refreshInterval: "10080m" # 1 week
  target:
    template:
      type: kubernetes.io/basic-auth
      engineVersion: v2
      data:
        password: "{{ .password }}"
        username: user
  dataFrom:
    - sourceRef:
        generatorRef:
          apiVersion: generators.external-secrets.io/v1alpha1
          kind: Password
          name: password

---
apiVersion: redhatcop.redhat.io/v1alpha1
kind: DatabaseSecretEngineConfig
metadata:
  name: base
spec:
  authentication:
    path: ${cluster_name}
    role: database-engine-admin
    serviceAccount:
      name: vault
  pluginName: postgresql-database-plugin
  allowedRoles:
    - role-read-write
    - role-read-only
  rootCredentials:
    secret:
      name: user
  rootPasswordRotation:
    enable: false
  passwordAuthentication: scram-sha-256
  passwordPolicy: password-policy
  connectionURL: replaceme
  path: replaceme

I'm actually reproducing this on every DatabaseSecretEngineConfig I set up. I'm saddly using an older version of Hashicorp Vault but since secret watching is done on kubernetes sides, I believe it should not impact how this feature works.

If I delete the DatabaseSecretEngineConfig resources and recreate it, the connection is also recreated in Vault, with an updated password.

I did not find any issue referencing this and it seems pretty basic so I'm wondering if I missed something. Please do not hesitate to tell me if the problem is between the chair and the keyboard.

[raffaelespazzoli]

yeah this controller is designed to read the password once from the secret and then ignore it. If password rotation is desired, the way that was designed in Vault is that Vault will do the rotation itself. That flag is available.

…

On Mon, Jan 19, 2026 at 10:42 AM Vianney Bouchaud ***@***.***> wrote: *vbouchaud* created an issue (redhat-cop/vault-config-operator#297) <#297> I'm currently working in an environment where the priviledged database user's password I'm referencing in a DatabaseSecretEngineConfig is updated regularly using an ExternalSecret with a Generator. Database engine is postgresql and, if it matters to the issue at and, it's provisioned on GCP CloudSQL through yaml resources too (kubernetes config connector). The priviledged user's password is correctly updated in the pg instance. Contrary to what is written in the documentation for the DatabaseSecretEngineConfig, it seems vault-config-operator does not watch for changes in kubernetes secrets where user credentials are provided. I mean here that when the DatabaseSecretEngineConfig is first created, DatabaseSecretEngineRole are then working as intended. I'm able to create dynamic roles in the database without issue. After a while (after the priviledged account's password rotated), I get the following error: * unable to start transaction: failed to connect to `host=instance-postgres-1.foo.bar user=baz database=quux`: failed SASL auth (FATAL: password authentication failed for user "baz" (SQLSTATE 28P01)) This is the manifest I wrote to define a connexion (minus some later kustomization patches): # ExternalSecret resources for reference (you can see the type basic-auth of the secret it will generate) ---apiVersion: external-secrets.io/v1kind: ExternalSecretmetadata: name: userspec: refreshInterval: "10080m" # 1 week target: template: type: kubernetes.io/basic-auth engineVersion: v2 data: password: "{{ .password }}" username: user dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: Password name: password ---apiVersion: redhatcop.redhat.io/v1alpha1kind: DatabaseSecretEngineConfigmetadata: name: basespec: authentication: path: ${cluster_name} role: database-engine-admin serviceAccount: name: vault pluginName: postgresql-database-plugin allowedRoles: - role-read-write - role-read-only rootCredentials: secret: name: user rootPasswordRotation: enable: false passwordAuthentication: scram-sha-256 passwordPolicy: password-policy connectionURL: replaceme path: replaceme I'm actually reproducing this on every DatabaseSecretEngineConfig I set up. I'm saddly using an older version of Hashicorp Vault but since secret watching is done on kubernetes sides, I believe it should not impact how this feature works. If I delete the DatabaseSecretEngineConfig resources and recreate it, the connection is also recreated in Vault, with an updated password. I did not find any issue referencing this and it seems pretty basic so I'm wondering if I missed something. Please do not hesitate to tell me if the problem is between the chair and the keyboard. — Reply to this email directly, view it on GitHub <#297>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPERXE7R4KSXGQI2P2ZYZD4HT3M5AVCNFSM6AAAAACSFTF3LWVHI2DSMVQWIX3LMV43ASLTON2WKOZTHAZTAMRVHAYTMOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- ciao/bye Raffaele

[vbouchaud]

Thanks for the quick reply.

I had a look at the documentation for the DatabaseSecretEngineConfig and it reads:

The password and possibly the username can be retrived a three different ways:

1. From a Kubernetes secret, specifying the rootCredentialsFromSecret field. The secret must be of basic auth type. If the secret is updated this connection will also be updated.

So I guess, sadly, the documentation needs to be updated.

I actually wonders: would you accept patches that would implement that feature?

[raffaelespazzoli]

Of course I d accept a pr. And perhaps I didn't remember correctly. If the doc says the connection should be refreshed, then maybe we have a bug. ciao/bye Raffaele

…

On Mon, Jan 19, 2026, 7:02 PM Vianney Bouchaud ***@***.***> wrote: *vbouchaud* left a comment (redhat-cop/vault-config-operator#297) <#297 (comment)> Thanks for the quick reply. I had a look at the documentation for the DatabaseSecretEngineConfig and it reads: The password and possibly the username can be retrived a three different ways: 1. From a Kubernetes secret, specifying the rootCredentialsFromSecret field. The secret must be of basic auth type. If the secret is updated this connection will also be updated. So I guess, sadly, the documentation needs to be updated. I actually wonders: would you accept patches that would implement that feature? — Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPERXDSACRDWUJRM3FIGDD4HVWDDAVCNFSM6AAAAACSFTF3LWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONZQGQ4DONZYGU> . You are receiving this because you commented.Message ID: ***@***.***>

[vbouchaud]

So i just had a look at the controller for the DatabaseSecretEngineConfig resource and it looks like there is a reconciler that watches secrets and on change will try to find the related DatabaseSecretEngineConfig and add it to a queue to be reconciled, see

vault-config-operator/controllers/databasesecretengineconfig_controller.go

Line 214 in 5f2df52

Watches(&corev1.Secret{

.

I didn't see any log that might be related in the vault-config-operator (I'm running 0.8.37) but I read the sources and noticed the default sync period used is 10h (vaultresourcecontroller.NewDefaultPeriodicReconcilePredicate() and syncPeriod default to 10h unless specified otherwise with env var). I reduced it to a few minutes, since I don't want the configuration to be out of date when some application later asks for credentials and so far it fixed the issue I'm encountering.

I guess it was just a sync interval issue (I must say 10h might be quite a long time for some use cases).

Thank you for your work on this project!

/close

[vbouchaud]

I'm reopening this issue because I thought it worked but apparently it didn't.

This is just a notice to say I will be investigating this issue for a bit.

[raffaelespazzoli]

thank you, my guess is that there is no way to read the pwd once configured in vault, so the operator cannot know if anything has changed and therefore cannot make the decision on whether to update. But I have not looked at the code in a while.

…

On Wed, Jan 21, 2026 at 9:34 AM Vianney Bouchaud ***@***.***> wrote: *vbouchaud* left a comment (redhat-cop/vault-config-operator#297) <#297 (comment)> I'm reopening this issue because I thought it worked but apparently it didn't. This is just a notice to say I will be investigating this issue for a bit. — Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPERXD2C5WXI33GO6JVOOD4H6E6FAVCNFSM6AAAAACSFTF3LWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONZYGQ2TGMZWGE> . You are receiving this because you commented.Message ID: ***@***.***>

-- ciao/bye Raffaele