[jira] [Created] (CAMEL-25518) camel-hashicorp-vault - secret refresh never detects updates of secrets outside the "secret" engine, nor updates made before its first check

["shashank (Jira)" <ji...@apache.org>]

shashank created CAMEL-25518:
--------------------------------

             Summary: camel-hashicorp-vault - secret refresh never detects updates of secrets outside the "secret" engine, nor updates made before its first check
                 Key: CAMEL-25518
                 URL: https://issues.apache.org/jira/browse/CAMEL-25518
             Project: Camel
          Issue Type: Bug
          Components: camel-hashicorp-vault
            Reporter: shashank


The secret refresh added by CAMEL-22676 ({{camel.vault.hashicorp.refreshEnabled=true}}) polls {{<engine>/metadata/<secret>}} for every tracked secret. Besides the names listed in {{camel.vault.hashicorp.secrets}}, it tracks every secret resolved with the {{hashicorp:}} properties function; when that option is not set, the documentation says the task takes into account all the properties with a {{hashicorp:}} prefix.

1. {{HashicorpVaultPropertiesFunction.getSecretFromSource}} records only the key: {{secrets.add(key)}} (line 214 at main c578a42a776d), so {{hashicorp:kv:db#password}} is recorded as {{db}}. {{HashicorpVaultReloadTriggerTask.buildMetadataPath}} (lines 272-297) reads a name without an engine from the {{secret}} engine, so it reads {{secret/metadata/db}}, which does not exist; {{VaultTemplate.read}} returns null and the task skips it without a log. For a secret in any engine other than {{secret}} (for example {{kv}}), an update never triggers a reload unless the user also lists it as {{kv:db}} in {{camel.vault.hashicorp.secrets}}.
2. The first run of the task only records the version it reads (lines 212-215: "First time seeing this secret, just record the version"). The first run happens one refresh period after startup (60 s by default). If the secret is updated in that window, the new version becomes the baseline and the application keeps the value it resolved at startup until the secret changes again.

h3. Reproduction

New {{HashicorpVaultReloadTriggerTaskTest}} with a minimal in-process fake of the Vault KV v2 HTTP API (JDK {{HttpServer}}, no container): resolve {{hashicorp:kv:db#password}} (version 1), run the task, set version 2, run the task; and resolve {{hashicorp:secret:api#password}} (version 1), set version 2, run the task. On main:
{noformat}
rotationInNonDefaultEngineIsDetected: the refresh task must read the metadata of the engine the secret was resolved from, but read [secret/metadata/db, secret/metadata/db] ==> expected: <true> but was: <false>
rotationBeforeFirstCheckIsDetected: the application resolved version 1 but version 2 was not detected, updates: {} ==> expected: <false> but was: <true>
secretsAreTrackedWithTheirEngine: expected: <[api, kv:db]> but was: <[api, db]>
{noformat}

h3. Proposed fix

The properties function records the secret in the format of {{camel.vault.hashicorp.secrets}}: {{engine:secret}}, or only {{secret}} for the default {{secret}} engine (so the names of secrets in the {{secret}} engine do not change, and a resolved secret has the same name as when it is listed in the option, so it is not checked twice). It also remembers the version it read ({{data.metadata.version}} of the KV v2 response; not when a specific {{@version}} was requested). For a secret the task has not seen before, it starts from that version, so a newer version in Vault triggers a reload at the first check. {{getSecrets()}} and the task's updates now name secrets of other engines {{engine:secret}}; component docs and a 4.23 upgrade guide note updated. The recorded set and the new version map are concurrent collections, as the refresh task reads them from its own thread. camel-hashicorp-vault unit tests: 6, 0 failures (the ITs need a Vault container and were not run).

Found with a TLA+ model of startup resolution, rotations and the check runs (metadata read, version compare, reload): "after a complete check run with no update since it started, the application uses the current version of every secret" is violated for a {{kv}} secret relying on auto-detection (12 steps: resolve, two check runs around one update, no reload) and for an update before the first check (8 steps); it holds on main for the {{secret}} engine with updates after the first check, and with {{camel.vault.hashicorp.secrets=kv:db}}. With the fix it holds for two secrets in different engines with two updates at any time. Then confirmed with the real classes as above.

Workaround on affected versions: list every secret of a non-default engine as {{engine:secret}} in {{camel.vault.hashicorp.secrets}} (fixes 1, not 2).

Affected: 4.17.0 and later (camel-4.18.x and camel-4.22.x have the same code; camel-4.14.x has no secret refresh).

Duplicate check (2026-10-09): JIRA component camel-hashicorp-vault (7 issues, none about the refresh), text "HashicorpVaultReloadTriggerTask" (none), "hashicorp" with "refresh"/"reload"/"engine" (9; CAMEL-22676/22677 added the feature, CAMEL-24636 is the re-authentication SPI); GitHub pull requests "hashicorp refresh", "HashicorpVaultReloadTriggerTask": none; no open PR touches camel-hashicorp-vault.

_Filed with Claude Code on behalf of allthingssecurity._




--
This message was sent by Atlassian Jira
(v8.20.10#820010)