HashiCorp Vault

At the component level, you set general and shared configurations that are, then, inherited by the endpoints. It is the highest configuration level.

For example, a component may have security settings, credentials for authentication, urls for network connection and so forth.

Some components only have a few options, and others may have many. Because components typically have pre-configured defaults that are commonly used, then you may often only need to configure a few options on a component; or none at all.

You can configure components using:

You usually spend more time setting up endpoints because they have many options. These options help you customize what you want the endpoint to do. The options are also categorized into whether the endpoint is used as a consumer (from), as a producer (to), or both.

Configuring endpoints is most often done directly in the endpoint URI as path and query parameters. You can also use the Endpoint DSL and DataFormat DSL as a type safe way of configuring endpoints and data formats in Java.

A good practice when configuring options is to use Property Placeholders.

Property placeholders provide a few benefits:

The following two sections list all the options, firstly for the component followed by the endpoint.

When using a HashiCorp Vault Cloud instance, in addition to the standard parameters such as host, port, scheme, and token, you must configure the following additional parameters:

The authentication option chooses how the component logs in to HashiCorp Vault:

When the login method is not mounted at its default path in Vault (approle, kubernetes or jwt), set the path with authMountPath, without auth/.

Camel renews the token before it expires, and logs in again when the token can no longer be renewed, such as when it reached its maximum time to live. A JWT read from a file is read again at every login, so a token that the platform replaces in the file, such as a projected service account token, is picked up. When the endpoint stops, Camel revokes the token of its login. A token given for the token login is renewed when it is renewable, but never revoked.

On HashiCorp Cloud (cloud=true and a namespace), the login is made in the namespace, as are the renewal and the revocation of the token.

For example, an endpoint that logs in with an AppRole, whose role ID and secret ID are in environment variables:

The component, the properties function and the secret refresh task also work with OpenBao, the open source fork of HashiCorp Vault, which keeps the API of Vault. OpenBao has the token, AppRole, Kubernetes and JWT logins built in.

The producer works on a secrets engine, given as the path of the endpoint (secret is the default key/value engine), and connects with the host, port, scheme and token endpoint options. The operation option selects what to do, and secretPath names the secret to work on; the CamelHashicorpVaultProducerOperation and CamelHashicorpVaultSecretPath headers override them per message.

To use this function, you’ll need to provide credentials for HashiCorp Vault as environment variables:

You can also configure the credentials in the application.properties file such as:

In case the running HashiCorp Vault instance you’re pointing is running on HashiCorp Cloud, the configuration will require two additional parameters:

You can also set the same in the application.properties file such as:

This will make the Properties function works even in the HashiCorp Cloud deployment option.

The properties function logs in with a token by default. To log in another way, set the options of Logging in to HashiCorp Vault with the camel.vault.hashicorp prefix. For example, an application in a Kubernetes pod logs in with the service account of the pod:

The properties function also reads these options from the environment variables CAMEL_HASHICORP_VAULT_AUTHENTICATION, CAMEL_HASHICORP_VAULT_ROLE_ID, CAMEL_HASHICORP_VAULT_SECRET_ID, CAMEL_HASHICORP_VAULT_ROLE, CAMEL_HASHICORP_VAULT_JWT, CAMEL_HASHICORP_VAULT_JWT_FILE and CAMEL_HASHICORP_VAULT_AUTH_MOUNT_PATH. When any of the CAMEL_HASHICORP_VAULT_* environment variables is set, the properties function takes all its settings from the environment variables, and none from the camel.vault.hashicorp configuration. The secret refresh task logs in the same way as the properties function.

At this point, you’ll be able to reference a property in the following way:

Where route will be the name of the secret stored in the HashiCorp Vault instance, in the 'secret' engine.

You could specify a default value in case the secret is not present on HashiCorp Vault instance:

In this case, if the secret doesn’t exist in the 'secret' engine, the property will fall back to "default" as value.

Also, you are able to get a particular field of the secret, if you have, for example, a secret named database of this form:

You’re able to do get single secret value in your route, in the 'secret' engine, like for example:

Or re-use the property as part of an endpoint.

You could specify a default value in case the particular field of secret is not present on HashiCorp Vault instance, in the 'secret' engine:

In this case, if the secret doesn’t exist or the secret exists (in the 'secret' engine) but the username field is not part of the secret, the property will fall back to "admin" as value.

There is also the syntax to get a particular version of the secret for both the approach, with field/default value specified or only with secret:

This approach will return the RAW route secret with version '2', in the 'secret' engine.

This approach will return the route secret value with version '2' or default value in case the secret doesn’t exist or the version doesn’t exist (in the 'secret' engine).

This approach will return the username field of the database secret with version '2' or admin in case the secret doesn’t exist or the version doesn’t exist (in the 'secret' engine).

The only requirement is adding the camel-hashicorp-vault jar to your Camel application.

Being able to reload Camel context on a Secret Refresh could be done by specifying the usual credentials (the same used for HashiCorp Vault Property Function).

With Environment variables:

or as plain Camel main properties:

To enable the automatic refresh, you’ll need additional properties to set:

where camel.vault.hashicorp.refreshEnabled will enable the automatic context reload, camel.vault.hashicorp.refreshPeriod is the interval of time between two different checks for update events (default 60000ms), and camel.vault.hashicorp.secrets is a comma-separated list of secret names (or patterns) to check for updates.

The secret names should use the following format: - mysecret or path/to/secret - tracks a secret in the default secret engine - myengine:mysecret or myengine:path/to/secret - tracks a secret in the myengine engine (use : to separate engine from path) - You can use patterns like database* to match multiple secrets

Note that camel.vault.hashicorp.secrets is not mandatory: if not specified the task responsible for checking updates events will take into account all the properties with a hashicorp: prefix. Such a secret is tracked in the engine of the property, in the format above (hashicorp:myengine:mysecret is tracked as myengine:mysecret, hashicorp:secret:mysecret as mysecret), and its first check compares the version in Vault with the version that was resolved, so an update made before the first check also triggers a reload.

HashiCorp Vault Spring Boot component starter offers the ability to early resolve properties, so the end user could resolve properties directly in the application.properties before both Spring Boot runtime and Camel context will start.

This could be accomplished in the following way. You should specified this property in your application.properties file:

This will enable the feature so you’ll be able to resolved properties, in your application.properties file, like: