Claus Ibsen created CAMEL-25675:
-----------------------------------
Summary: camel-hashicorp-vault: support AppRole, Kubernetes, JWT
and cloud logins
Key: CAMEL-25675
URL: https://issues.apache.org/jira/browse/CAMEL-25675
Project: Camel
Issue Type: Improvement
Components: camel-hashicorp-vault
Reporter: Claus Ibsen
Fix For: 4.24.0
Camel's HashiCorp Vault support logs in only with a fixed token, and never
renews it. A fixed token is the weakest login for an application: it is the one
secret that unlocks all the others, so it ends up in an env var or a properties
file, and it expires (Vault and OpenBao default to a maximum of 768h). Users
who run Vault in Kubernetes or in a cloud, for example on Azure, expect the
application to log in with the identity the platform already gives it.
h3. Today
* The properties function ({{HashicorpVaultPropertiesFunction}}), the secret
refresh task ({{HashicorpVaultReloadTriggerTask}}) and the endpoint's default
client ({{HashicorpVaultEndpoint}}) each create {{new VaultTemplate(endpoint,
new TokenAuthentication(token))}}.
* That constructor gives the VaultTemplate Spring Vault's
{{SimpleSessionManager}}, which never renews the token. A periodic token stops
working after its first period.
* The vault configuration ({{HashicorpVaultConfiguration}} in camel-api, the
camel.vault.hashicorp options in camel-main, and env vars such as
{{CAMEL_HASHICORP_VAULT_TOKEN}}) has a token and no other login.
* Workarounds: the endpoint takes a {{vaultTemplate}} option, so a user can
build a client with another login. The properties function has a constructor
that takes a VaultTemplate, but {{doStart}} replaces it, or fails when no token
is set.
h3. Proposal
One option chooses the login, with its own settings, for the properties
function, the refresh task and the endpoint alike. Spring Vault 4.1.0, already
a dependency, has a class for each:
* token, as today
* AppRole: role ID and secret ID ({{AppRoleAuthentication}})
* Kubernetes: the pod's service-account token ({{KubernetesAuthentication}})
* JWT: a workload identity token, for example from a CI job
({{JwtAuthentication}})
* TLS client certificate ({{ClientCertificateAuthentication}})
* cloud identities: AWS IAM ({{AwsIamAuthentication}}), Azure managed identity
({{AzureMsiAuthentication}}), GCP ({{GcpComputeAuthentication}},
{{GcpIamCredentialsAuthentication}})
Use Spring Vault's {{LifecycleAwareSessionManager}}, so tokens are renewed and
the application logs in again when a token can no longer be renewed.
Notes:
* Dependencies: the AWS IAM login needs the AWS SDK v2
(software.amazon.awssdk), and the GCP IAM credentials login needs the Google
auth and IAM credentials libraries. Spring Vault declares them optional. Keep
them optional in camel-hashicorp-vault and document which one each login needs.
Azure managed identity, AppRole, Kubernetes and JWT need nothing extra.
* Azure: {{AzureMsiAuthentication}} reads the Azure instance metadata service
(169.254.169.254), which Azure VMs and scale sets have. Check the Azure hosting
without it (App Service, Container Apps, AKS workload identity), where a JWT
login with the platform's identity token may be the way.
* Let the properties function keep a VaultTemplate it is given, instead of
replacing it in {{doStart}}.
h3. HashiCorp Vault and OpenBao
OpenBao, the Linux Foundation fork of Vault 1.14, keeps Vault's API, so the
same client code works with both servers. OpenBao has the AppRole, Kubernetes,
JWT/OIDC and TLS certificate logins built in. Its AWS, Azure and GCP logins are
first-party plugins (https://github.com/openbao/openbao-plugins) that the
server admin installs; nothing differs on the Camel side.
h3. Tests and docs
* camel-test-infra-hashicorp-vault runs
{{mirror.gcr.io/hashicorp/vault:2.1.2}}. The image is the
{{hashicorp.vault.container}} property, so the integration tests can also run
against an OpenBao image. The container sets its dev root token with
{{VAULT_DEV_ROOT_TOKEN_ID}}; OpenBao may need {{BAO_DEV_ROOT_TOKEN_ID}} (not
checked).
* AppRole, JWT and TLS certificate logins can be tested against the container.
Kubernetes and the cloud logins need a cluster or a cloud identity: test their
configuration, not the login itself.
* Document each login in the camel-hashicorp-vault docs and in the vault
configuration docs, and say it works with OpenBao once the tests run against it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
