VaultSecret refreshPeriod : default behavior with default configurations

[MrLuje]

This is a question as I'm not sure what should happen with the default behavior of vault + operator.

I have created a bunch of VaultSecret like the following :

apiVersion: redhatcop.redhat.io/v1alpha1
kind: VaultSecret
metadata:
  name: keycloak-secret
spec:
  vaultSecretDefinitions:
    - authentication:
        path: k8s/kubernetes
        role: tooling_dev-secret-reader
      name: keycloak_secret
      path: k8s/tooling_dev/namespace/tooling_dev/kv-namespace/data/keycloak-secret
  output:
    name: oauth2
    type: Opaque
    stringData:
      SOME: thing

and when looking at the operator logs, I'm seeing a lot of DEBUG controllers.VaultSecret Sync VaultSecret {"namespacedName": "tooling-dev/keycloak-secret}, like 1 every 1s for each VaultSecret.
If I specify VaultSecret.refreshPeriod to 1m, the logs lower to 1 every 1m as expected.

The VaultSecret.refreshPeriod doc states This takes precedence over any vault secret lease duration and can be used to force a refresh.

vault-config-operator/config/crd/bases/redhatcop.redhat.io_vaultsecrets.yaml

Lines 69 to 72 in c56bae0

	refreshPeriod:
	description: RefreshPeriod if specified, the operator will refresh
	the secret with the given frequency. This takes precedence over
	any vault secret lease duration and can be used to force a refresh.

By default, auth & mount have default_lease_ttl & max_lease_ttl to 0.
Is it evaluated as "since I have no idea when it will expires, I'll request it more often" ?

[MrLuje]

I added 1h of default_lease_ttl & max_lease_ttl to the mount and it doesn't have any effect on the refresh rate

[trevorbox]

Does the behavior work as documented if the SecretEngineMount is v2? This might just mean there is no lease information for v1 kv secrets. Regardless, it would be good to document that better.
Example:

apiVersion: redhatcop.redhat.io/v1alpha1
kind: SecretEngineMount
metadata:
  name: kv-v2
spec:
  authentication: 
    path: kubernetes
    role: kv-engine-admin-v2
  type: kv
  path: test-vault-config-operator
  options:
    version: "2"

[trevorbox]

Ok, its the other way around. The lease_duration is returned for kv v1 secret types, not kv v2.
So using a refreshPeriod should be required for kv v2, else it will attempt to refresh constantly (since the lease_duration is 0 always).

See hashicorp/vault#6274

example:

[tbox@fedora vault-config-operator]$ vault kv get -format=json -tls-skip-verify test-vault-config-operator/kv/randomsecret-password
{
  "request_id": "4e682998-02c1-00df-5e9d-f9d441a130d9",
  "lease_id": "",
  "lease_duration": 120,
  "renewable": false,
  "data": {
    "password": "wkfzdmeyqfdgtshrfehy"
  },
  "warnings": null
}
[tbox@fedora vault-config-operator]$ vault kv get -format=json -tls-skip-verify /test-vault-config-operator/kv-v2/randomsecret-another-password-v2
{
  "request_id": "b3150234-dd48-6406-f945-ba1ca0f2113a",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "data": {
      "password": "wtvdwmwclhyebstggsxl"
    },
    "metadata": {
      "created_time": "2023-02-27T23:02:27.914618222Z",
      "custom_metadata": null,
      "deletion_time": "",
      "destroyed": false,
      "version": 5
    }
  },
  "warnings": null
}

[MrLuje]

Good catch, thanks for digging that up!

[raffaelespazzoli]

can we close this?

[MrLuje]

Yes, nothing to be done on the operator side.
Do you mind if I open a PR to clarify the docs for v1 & v2 behaviors ?