oscerd opened a new pull request, #29235: URL: https://github.com/apache/camel/pull/29235
## Summary The `hashicorp-vault` endpoint, the `hashicorp:` properties function and the secret refresh task logged in only with a fixed token, and never renewed it (Spring Vault's `SimpleSessionManager`). This PR is the first of three for [CAMEL-25675](https://issues.apache.org/jira/browse/CAMEL-25675). It adds the logins that need no extra library, and keeps the token valid. - A new `authentication` option chooses the login: `token` (the default, as before), `approle` (`roleId`, `secretId`), `kubernetes` (`role`, the pod's service account token) or `jwt` (`jwt` or `jwtFile`, optional `role`). `authMountPath` sets the path of a login method that is not mounted at its default path. The options exist on the endpoint and as `camel.vault.hashicorp.*`. The properties function also reads them from new `CAMEL_HASHICORP_VAULT_*` environment variables. - The endpoint, the properties function and the secret refresh task now create their client the same way (`HashicorpVaultClient`). It uses Spring Vault's `LifecycleAwareSessionManager`, which renews the token before it expires and logs in again when the token can no longer be renewed. Each owner closes its client when it stops, which revokes the token of a login. A token given for the token login is renewed when it is renewable, but never revoked. The renewal runs on a thread of Camel's `ExecutorServiceManager`. - A JWT in `jwtFile` is read again at every login, so a projected service account token that the platform replaces is picked up. - On HashiCorp Cloud (`cloud=true` and a `namespace`), the login, and the renewal and revocation of its token, are sent to the namespace (`X-Vault-Namespace`). Secrets are still read with the namespace in their path, as before. - The properties function keeps a `VaultTemplate` it is created with. Before, `doStart` replaced it, or failed when no token was configured. - `roleId`, `secretId` and `jwt` are marked `security = "secret"`, and added to the sensitive keys (`UpdateSensitizeHelper.EXTRA_KEYS`, regenerated `SensitiveUtils` and `sensitive-keys.json`). The generator collects only component-level options, and the component has these on the endpoint only, so camel-main would otherwise log `camel.vault.hashicorp.secretId` in clear. - The test infra also sets `BAO_DEV_ROOT_TOKEN_ID`, so the integration tests can run against an OpenBao image (`-Dhashicorp.vault.container=quay.io/openbao/openbao:2.7.2`). OpenBao ignores `VAULT_DEV_ROOT_TOKEN_ID`. ## Behavior changes (upgrade guide 4.24) - With a token, Camel looks the token up (`auth/token/lookup-self`) at the first request, and renews it when it is renewable. Vault's `default` policy allows both. A token that cannot look itself up logs a warning and works as before. - Requests to Vault time out after 5 s to connect and 15 s to read, Spring Vault's defaults. Before, they had no timeout. This also bounds the token revocation on stop. - An endpoint without a `vaultTemplate` is validated when it is created: host, port and scheme, and the settings of its login. - `camel.vault.hashicorp.token` is no longer marked `required`. CAMEL-22351 marked it as required when the token was the only login; it is now needed only by the token login. - The `hashicorp-secrets` dev console shows the login (`Token`, `AppRole`, ...) instead of `OAuth Token`. ## Not in this PR (next PRs for CAMEL-25675) - TLS settings (trust store, client certificate) and the `cert` login. - The cloud logins: `aws-iam`, `azure-msi`, `gcp-gce` and `gcp-iam`. They need cloud-specific options (Spring Vault requests the Azure managed identity token for the resource `https://vault.hashicorp.com`, while Vault's Azure login is usually set up for `https://management.azure.com/`), and `aws-iam` and `gcp-iam` need optional libraries. - camel-spring-boot keeps its own copy of the `camel.vault.hashicorp.*` options, which needs a follow-up there. ## Tests - `HashicorpVaultClientTest` (fake Vault over HTTP): each login's request, the token sent with the reads, the mount path, renewal before expiry, login again after a failed renewal, re-reading the JWT file, a given token renewed but never revoked, the namespace header on HashiCorp Cloud only, and the validation messages. - `HashicorpVaultClientSettingsTest`: environment variables against configuration. - `HashicorpVaultLoginTest`: the properties function and the endpoint log in as configured and revoke their token on stop; an endpoint missing a setting of its login is rejected. - `HashicorpVaultLoginIT`: AppRole and JWT (from a value and from a file) against Vault, for the properties function and the endpoint. - All 36 integration tests of the module pass against `mirror.gcr.io/hashicorp/vault:2.2.1` and against `quay.io/openbao/openbao:2.7.2`; the 57 unit tests pass. - Full reactor build (`mvn clean install -DskipTests -DskipITs`) with the regenerated files committed. _Claude Code on behalf of oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
