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, jwt, cert, aws for aws-iam, azure for azure-msi or gcp for gcp-gce), 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:

With the https scheme, the component trusts the certificate of Vault as any other TLS connection of the JVM does. For a Vault whose certificate is signed by a private CA, set trustStore to the certificates to trust: a PKCS12 or JKS trust store with its trustStorePassword, or a PEM file with the CA certificates, such as the file that the VAULT_CACERT environment variable of the Vault CLI points to.

To present a client certificate to Vault, for the cert login or for a Vault that requires client certificates, set keyStore: a PKCS12 or JKS key store with its keyStorePassword, or a PEM file with the certificate and its private key. The key of a PEM file is not encrypted, in PKCS#8 (-----BEGIN PRIVATE KEY-----) or, for an RSA key, in PKCS#1 (-----BEGIN RSA PRIVATE KEY-----).

The trust store and the key store are read when the client is created, when the endpoint, the properties function or the secret refresh task starts. A certificate replaced in its file, such as a client certificate renewed before it expires, is used after a restart.

For example, the properties function logs in with a client certificate:

The aws-iam login signs a request to AWS STS with the credentials of the AWS SDK default chain: the environment variables, the system properties, a web identity token (such as IAM roles for service accounts on Amazon EKS), the profile, the container credentials (Amazon ECS) or the instance profile (Amazon EC2). Vault checks the request with STS. The login needs the AWS SDK: add the software.amazon.awssdk:auth dependency, in the version of the AWS SDK of the Camel AWS components. A web identity token also needs the software.amazon.awssdk:sts dependency, and an SSO profile the software.amazon.awssdk:sso and software.amazon.awssdk:ssooidc dependencies. Without the sts module, the AWS SDK skips the web identity token and takes the next credentials of the chain, such as those of the instance: so Camel refuses to start the login when a web identity token is set (AWS_WEB_IDENTITY_TOKEN_FILE) and the sts module is missing.

The request is sent to awsStsEndpoint, by default the global endpoint https://sts.amazonaws.com/, which takes requests signed for us-east-1. Without awsStsEndpoint and awsRegion, the request is signed for us-east-1, whatever the region of the application, as vault login -method=aws does. To use a regional endpoint, set awsStsEndpoint and its region in awsRegion, as the AWS login of Vault is configured (sts_endpoint and sts_region); without awsRegion, the request is then signed for the region of the AWS SDK default region chain, such as the AWS_REGION environment variable. awsIamServerId sets the X-Vault-AWS-IAM-Server-ID header, when the AWS login of Vault requires one.

For example, the properties function logs in with the AWS credentials of the application, through the STS endpoint of its region:

The azure-msi login asks the Azure instance metadata service (169.254.169.254) for a token of the managed identity of the virtual machine, for the resource azureResource, by default https://management.azure.com/, which must be the resource of the Azure login of Vault (auth/azure/config). azureClientId chooses a user-assigned managed identity, instead of the system-assigned one. The instance metadata service is on Azure virtual machines and scale sets. A pod of Azure Kubernetes Service with workload identity has a token in the file named by the AZURE_FEDERATED_TOKEN_FILE environment variable instead, for the jwt login with jwtFile.

The gcp-gce login asks the metadata server of a Google Compute Engine instance for an identity token of the default service account of the instance, for a role of type gce of the GCP login of Vault.

The metadata services are reached directly, never through an HTTP proxy.

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, JWT and TLS certificate 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, and the settings of TLS from CAMEL_HASHICORP_VAULT_TRUST_STORE, CAMEL_HASHICORP_VAULT_TRUST_STORE_PASSWORD, CAMEL_HASHICORP_VAULT_KEY_STORE and CAMEL_HASHICORP_VAULT_KEY_STORE_PASSWORD, and the settings of the Cloud logins from CAMEL_HASHICORP_VAULT_AWS_IAM_SERVER_ID, CAMEL_HASHICORP_VAULT_AWS_REGION, CAMEL_HASHICORP_VAULT_AWS_STS_ENDPOINT, CAMEL_HASHICORP_VAULT_AZURE_RESOURCE and CAMEL_HASHICORP_VAULT_AZURE_CLIENT_ID. 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: