[
https://issues.apache.org/jira/browse/CAMEL-25675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino reassigned CAMEL-25675:
----------------------------------------
Assignee: Andrea Cosentino
> 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
> Assignee: Andrea Cosentino
> Priority: Major
> 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)
