Security

Camel offers several forms and levels of security capabilities that can be used on Camel routes. These various forms of security may be used in conjunction with each other or separately.

This page describes the security features Camel offers to route authors and operators. For the project’s security model - who is trusted, where the trust boundaries sit, what counts as a framework vulnerability, and what is operator responsibility - see Security Model.

Camel also includes a Security Policy Enforcement mechanism that detects insecure configuration (plain-text secrets, disabled SSL verification, unsafe deserialization, dev features in production) at startup time.

The broad categories offered are:

  • Route Security - Authentication and Authorization services to proceed on a route or route segment

  • Payload Security - Data Formats that offer encryption/decryption services at the payload level

  • Endpoint Security - Security offered by components that can be utilized by endpointUri associated with the component

  • Configuration Security - Security offered by encrypting sensitive information from configuration files or external Secured Vault systems.

Camel offers the JSSE Utility for configuring SSL/TLS related aspects of a number of Camel components.

Route Security

Authentication and Authorization Services

Camel offers Route Policy driven security capabilities that may be wired into routes or route segments. A route policy in Camel utilizes a strategy pattern for applying interceptors on Camel Processors. It’s offering the ability to apply cross-cutting concerns (for example. security, transactions etc.) of a Camel route.

The components offering authentication and authorization services utilizing Route Policy based on org.apache.camel.spi.AuthorizationPolicy are:

Payload Security

Camel offers encryption/decryption services to secure payloads or selectively apply encryption/decryption capabilities on portions/sections of a payload.

The data-formats offering encryption/decryption of payloads utilizing Marshal are:

Endpoint Security

Some components in Camel offer an ability to secure their endpoints (using interceptors etc.) and therefore ensure that they offer the ability to secure payloads as well as provide authentication/authorization capabilities at endpoints created using the components.

Post-Quantum Cryptography

Camel provides Post-Quantum Cryptography (PQC) protection at two complementary layers:

  • Transport layer (TLS). On JDK 25+, Camel automatically configures hybrid post-quantum key exchange (X25519MLKEM768) on all SSLContextParameters to protect connections against harvest-now-decrypt-later attacks. See PQC TLS Configuration for the full configuration guide.

  • Message layer. The PQC component and PQC data format encrypt and sign message payloads using post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA, and more), protecting data independently of the transport.

Configuration Security

Camel offers the Properties component to externalize configuration values to properties files. Those values could contain sensitive information such as usernames and passwords.

Those values can be encrypted and automatically decrypted by Camel using:

Camel also supports accessing the secured configuration from an external vault systems.

Configuration Security using Vaults

The following Vaults are supported by Camel:

Vault Usage Syntax

All vault providers use the same property placeholder syntax. The prefix identifies which vault to use:

Provider Prefix Required JAR

AWS Secrets Manager

aws:

camel-aws-secrets-manager

Google Secret Manager

gcp:

camel-google-secret-manager

Azure Key Vault

azure:

camel-azure-key-vault

Hashicorp Vault

hashicorp:

camel-hashicorp-vault

IBM Secrets Manager

ibm:

camel-ibm-secrets-manager

CyberArk Conjur

cyberark:

camel-cyberark-vault

The following syntax forms are supported (replace <prefix> with the provider prefix from the table above):

{{<prefix>:secretName}}                        (1)
{{<prefix>:secretName:defaultValue}}           (2)
{{<prefix>:secretName#fieldName}}              (3)
{{<prefix>:secretName#fieldName:defaultValue}} (4)
1 Lookup the secret value. Fails if the secret does not exist.
2 Lookup the secret value, falling back to defaultValue if the secret does not exist.
3 Lookup a specific field from a JSON-structured secret.
4 Lookup a specific field, with a fallback default value.

For example, if you have a JSON secret named database:

{
  "username": "admin",
  "password": "password123",
  "engine": "postgres",
  "host": "127.0.0.1",
  "port": "3128",
  "dbname": "db"
}

You can access individual fields using the # syntax:

  • Java

  • XML

  • YAML

from("direct:start")
  .log("Username is {{aws:database#username}}")
  .log("Password is {{aws:database#password:secret}}");
<route>
    <from uri="direct:start"/>
    <log message="Username is {{aws:database#username}}"/>
    <log message="Password is {{aws:database#password:secret}}"/>
</route>
- route:
    from:
      uri: direct:start
      steps:
        - log:
            message: "Username is {{aws:database#username}}"
        - log:
            message: "Password is {{aws:database#password:secret}}"

The examples above use the aws: prefix but the same syntax works with any provider prefix (gcp:, azure:, hashicorp:, ibm:, cyberark:).

Version Syntax

Hashicorp Vault, IBM Secrets Manager, and CyberArk Conjur support retrieving a specific version of a secret using the @ suffix:

{{hashicorp:secret:route@2}}                              (1)
{{hashicorp:route:defaultValue@2}}                        (2)
{{hashicorp:secret:database#username:admin@2}}            (3)
{{ibm:default:route@2}}                                   (4)
{{cyberark:route@2}}                                      (5)
1 Hashicorp: get secret route at version 2 from the secret engine.
2 Hashicorp: get secret route at version 2, with default fallback.
3 Hashicorp: get field username from secret database at version 2.
4 IBM: get secret route at version 2 from the default secret group.
5 CyberArk: get secret route at version 2.

Using AWS Vault

To use AWS Secrets Manager, you need to provide accessKey, secretKey and the region. This can be done using environmental variables before starting the application:

export $CAMEL_VAULT_AWS_ACCESS_KEY=accessKey
export $CAMEL_VAULT_AWS_SECRET_KEY=secretKey
export $CAMEL_VAULT_AWS_REGION=region

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

camel.vault.aws.accessKey = accessKey
camel.vault.aws.secretKey = secretKey
camel.vault.aws.region = region

If you want instead to use the AWS default credentials provider, you’ll need to provide the following env variables:

export $CAMEL_VAULT_AWS_USE_DEFAULT_CREDENTIALS_PROVIDER=true
export $CAMEL_VAULT_AWS_REGION=region

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

camel.vault.aws.defaultCredentialsProvider = true
camel.vault.aws.region = region

It is also possible to specify a particular profile name for accessing AWS Secrets Manager:

export $CAMEL_VAULT_AWS_USE_PROFILE_CREDENTIALS_PROVIDER=true
export $CAMEL_VAULT_AWS_PROFILE_NAME=test-account
export $CAMEL_VAULT_AWS_REGION=region

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

camel.vault.aws.profileCredentialsProvider = true
camel.vault.aws.profileName = test-account
camel.vault.aws.region = region

At this point you’ll be able to reference a property by using aws: as prefix in the {{ }} syntax. See Vault Usage Syntax for the full syntax reference.

The only requirement is adding camel-aws-secrets-manager JAR to your Camel application.

Using GCP Vault

To use GCP Secret Manager, you need to provide serviceAccountKey file and GCP projectId. This can be done using environmental variables before starting the application:

export $CAMEL_VAULT_GCP_SERVICE_ACCOUNT_KEY=file:////path/to/service.accountkey
export $CAMEL_VAULT_GCP_PROJECT_ID=projectId

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

camel.vault.gcp.serviceAccountKey = accessKey
camel.vault.gcp.projectId = secretKey

If you want instead to use the GCP default client instance, you’ll need to provide the following env variables:

export $CAMEL_VAULT_GCP_USE_DEFAULT_INSTANCE=true
export $CAMEL_VAULT_GCP_PROJECT_ID=projectId

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

camel.vault.gcp.useDefaultInstance = true
camel.vault.gcp.projectId = projectId

At this point you’ll be able to reference a property by using gcp: as prefix in the {{ }} syntax. See Vault Usage Syntax for the full syntax reference.

There are only two requirements: - Adding camel-google-secret-manager JAR to your Camel application. - Give the service account used permissions to do operation at secret management level (for example accessing the secret payload, or being admin of secret manager service)

Using Azure Key Vault

To use this function, you’ll need to provide credentials to Azure Key Vault Service as environment variables:

export $CAMEL_VAULT_AZURE_TENANT_ID=tenantId
export $CAMEL_VAULT_AZURE_CLIENT_ID=clientId
export $CAMEL_VAULT_AZURE_CLIENT_SECRET=clientSecret
export $CAMEL_VAULT_AZURE_VAULT_NAME=vaultName

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

camel.vault.azure.tenantId = accessKey
camel.vault.azure.clientId = clientId
camel.vault.azure.clientSecret = clientSecret
camel.vault.azure.vaultName = vaultName

Or you can enable the usage of Azure Identity in the following way:

export $CAMEL_VAULT_AZURE_IDENTITY_ENABLED=true
export $CAMEL_VAULT_AZURE_VAULT_NAME=vaultName

You can also enable the usage of Azure Identity in the application.properties file such as:

camel.vault.azure.azureIdentityEnabled = true
camel.vault.azure.vaultName = vaultName

At this point you’ll be able to reference a property by using azure: as prefix in the {{ }} syntax. See Vault Usage Syntax for the full syntax reference.

The only requirement is adding the camel-azure-key-vault JAR to your Camel application.

Using Hashicorp Vault

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

export $CAMEL_VAULT_HASHICORP_TOKEN=token
export $CAMEL_VAULT_HASHICORP_HOST=host
export $CAMEL_VAULT_HASHICORP_PORT=port
export $CAMEL_VAULT_HASHICORP_SCHEME=http/https

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

camel.vault.hashicorp.token = token
camel.vault.hashicorp.host = host
camel.vault.hashicorp.port = port
camel.vault.hashicorp.scheme = scheme

If the running Hashicorp Vault instance is on Hashicorp Cloud, two additional parameters are required:

export CAMEL_HASHICORP_VAULT_CLOUD=true
export CAMEL_HASHICORP_VAULT_NAMESPACE=namespace

Or in application.properties:

camel.vault.hashicorp.cloud = true
camel.vault.hashicorp.namespace = namespace

At this point you’ll be able to reference a property by using hashicorp: as prefix in the {{ }} syntax. Hashicorp Vault also supports version-specific lookups using the @ suffix. See Vault Usage Syntax for the full syntax reference.

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

Using IBM Secrets Manager Vault

To use this function, you’ll need to provide credentials for IBM Secrets Manager vault as environment variables:

export CAMEL_VAULT_IBM_TOKEN=token
export CAMEL_VAULT_IBM_SERVICE_URL=serviceUrl

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

camel.vault.ibm.token = token
camel.vault.ibm.serviceUrl = serviceUrl
If you’re running the application on a Kubernetes based cloud platform, you can initialize the environment variables from a Secret or Configmap to enhance security. You can also enhance security by setting a Secret property placeholder which will be initialized at application runtime only.
camel.vault.ibm configuration only applies to the IBM Secrets Manager Vault properties function (E.g when resolving properties). When using the operation option to create, get, list secrets etc., you should provide the token and serviceUrl options.

IBM Secrets Manager organizes secrets into secret groups. The syntax includes the group name (e.g. default): {{ibm:default:secretName}}, {{ibm:default:secretName:fallback}}, {{ibm:default:secretName#field}}, {{ibm:default:secretName#field:fallback}}. IBM also supports version-specific lookups using the @ suffix. See Vault Usage Syntax for the full syntax reference.

The only requirement is adding the camel-ibm-secrets-manager JAR to your Camel application.

Using CyberArk Conjur Vault

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

export CAMEL_VAULT_CYBERARK_URL=https://conjur.example.com
export CAMEL_VAULT_CYBERARK_ACCOUNT=myaccount
export CAMEL_VAULT_CYBERARK_USERNAME=admin
export CAMEL_VAULT_CYBERARK_API_KEY=3ahx8dy3...

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

camel.vault.cyberark.url = https://conjur.example.com
camel.vault.cyberark.account = myaccount
camel.vault.cyberark.username = admin
camel.vault.cyberark.apiKey = 3ahx8dy3...

Alternatively, you can use username and password authentication:

export CAMEL_VAULT_CYBERARK_URL=https://conjur.example.com
export CAMEL_VAULT_CYBERARK_ACCOUNT=myaccount
export CAMEL_VAULT_CYBERARK_USERNAME=admin
export CAMEL_VAULT_CYBERARK_PASSWORD=secretpassword

Or in application.properties:

camel.vault.cyberark.url = https://conjur.example.com
camel.vault.cyberark.account = myaccount
camel.vault.cyberark.username = admin
camel.vault.cyberark.password = secretpassword
If you’re running the application on a Kubernetes based cloud platform, you can initialize the environment variables from a Secret or ConfigMap to enhance security.
CyberArk Conjur requires secrets (variables) to be defined in a policy file before they can be set.

At this point you’ll be able to reference a property by using cyberark: as prefix in the {{ }} syntax. CyberArk also supports version-specific lookups using the @ suffix. See Vault Usage Syntax for the full syntax reference.

The only requirement is adding the camel-cyberark-vault JAR to your Camel application.

Automatic Camel context reloading on Secret Refresh while using AWS Secrets Manager

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

With Environment variables:

export $CAMEL_VAULT_AWS_USE_DEFAULT_CREDENTIALS_PROVIDER=accessKey
export $CAMEL_VAULT_AWS_REGION=region

or as plain Camel main properties:

camel.vault.aws.useDefaultCredentialProvider = true
camel.vault.aws.region = region

Or by specifying accessKey/SecretKey and region, instead of using the default credentials provider chain.

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

camel.vault.aws.refreshEnabled=true
camel.vault.aws.refreshPeriod=60000
camel.vault.aws.secrets=Secret
camel.main.context-reload-enabled = true

where camel.vault.aws.refreshEnabled will enable the automatic context reload, camel.vault.aws.refreshPeriod is the interval of time between two different checks for update events and camel.vault.aws.secrets is a regex representing the secrets we want to track for updates.

Note that camel.vault.aws.secrets is not mandatory: if not specified the task responsible for checking updates events will take into accounts or the properties with an aws: prefix.

The only requirement is adding the camel-aws-secrets-manager JAR to your Camel application.

Automatic Camel context reloading on Secret Refresh while using AWS Secrets Manager with EventBridge and AWS SQS Services

Another option is to use AWS EventBridge in conjunction with the AWS SQS service.

On the AWS side, the following resources need to be created:

  • an AWS CloudTrail trail

  • an AWS SQS Queue

  • an EventBridge rule of the following kind

{
  "source": ["aws.secretsmanager"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["secretsmanager.amazonaws.com"]
  }
}

This rule will make the event related to AWS Secrets Manager filtered

  • You need to set the Rule target to the AWS SQS Queue for EventBridge rule

  • You need to give permission to the EventBrige rule, to write on the above SQS Queue. For doing this you’ll need to define a json file like this:

{
    "Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"<queue_arn>/SQSDefaultPolicy\",\"Statement\":[{\"Sid\": \"EventsToMyQueue\", \"Effect\": \"Allow\", \"Principal\": {\"Service\": \"events.amazonaws.com\"}, \"Action\": \"sqs:SendMessage\", \"Resource\": \"<queue_arn>\", \"Condition\": {\"ArnEquals\": {\"aws:SourceArn\": \"<eventbridge_rule_arn>\"}}}]}"
}

Change the values for queue_arn and eventbridge_rule_arn, save the file with policy.json name and run the following command with AWS CLI

aws sqs set-queue-attributes --queue-url <queue_url> --attributes file://policy.json

where queue_url is the AWS SQS Queue URL of the just created Queue.

Now you should be able to set up the configuration on the Camel side. To enable the SQS notification, add the following properties:

camel.vault.aws.refreshEnabled=true
camel.vault.aws.refreshPeriod=60000
camel.vault.aws.secrets=Secret
camel.main.context-reload-enabled = true
camel.vault.aws.useSqsNotification=true
camel.vault.aws.sqsQueueUrl=<queue_url>

where queue_url is the AWS SQS Queue URL of the just created Queue.

Whenever an event of PutSecretValue for the Secret named 'Secret' will happen, a message will be enqueued in the AWS SQS Queue and consumed on the Camel side and a context reload will be triggered.

Automatic Camel context reloading on Secret Refresh while using Google Secret Manager

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

With Environment variables:

export $CAMEL_VAULT_GCP_USE_DEFAULT_INSTANCE=true
export $CAMEL_VAULT_GCP_PROJECT_ID=projectId

or as plain Camel main properties:

camel.vault.gcp.useDefaultInstance = true
camel.vault.aws.projectId = projectId

Or by specifying a path to a service account key file, instead of using the default instance.

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

camel.vault.gcp.projectId= projectId
camel.vault.gcp.refreshEnabled=true
camel.vault.gcp.refreshPeriod=60000
camel.vault.gcp.secrets=hello*
camel.vault.gcp.subscriptionName=subscriptionName
camel.main.context-reload-enabled = true

where camel.vault.gcp.refreshEnabled will enable the automatic context reload, camel.vault.gcp.refreshPeriod is the interval of time between two different checks for update events and camel.vault.gcp.secrets is a regex representing the secrets we want to track for updates.

Note that camel.vault.gcp.secrets is not mandatory: if not specified the task responsible for checking updates events will take into accounts or the properties with an gcp: prefix.

The camel.vault.gcp.subscriptionName is the subscription name created in relation to the Google PubSub topic associated with the tracked secrets.

This mechanism makes use of the notification system related to Google Secret Manager: through this feature, every secret could be associated with one up to ten Google Pubsub Topics. These topics will receive events related to the life cycle of the secret.

There are only two requirements: - Adding camel-google-secret-manager JAR to your Camel application. - Give the service account used permissions to do operation at secret management level (for example, accessing the secret payload, or being admin of secret manager service and also have permission over the Pubsub service)

Automatic Camel context reloading on Secret Refresh while using Azure Key Vault

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

With Environment variables:

export $CAMEL_VAULT_AZURE_TENANT_ID=tenantId
export $CAMEL_VAULT_AZURE_CLIENT_ID=clientId
export $CAMEL_VAULT_AZURE_CLIENT_SECRET=clientSecret
export $CAMEL_VAULT_AZURE_VAULT_NAME=vaultName

or as plain Camel main properties:

camel.vault.azure.tenantId = accessKey
camel.vault.azure.clientId = clientId
camel.vault.azure.clientSecret = clientSecret
camel.vault.azure.vaultName = vaultName

If you want to use Azure Identity with environment variables, you can do in the following way:

export $CAMEL_VAULT_AZURE_IDENTITY_ENABLED=true
export $CAMEL_VAULT_AZURE_VAULT_NAME=vaultName

You can also enable the usage of Azure Identity in the application.properties file such as:

camel.vault.azure.azureIdentityEnabled = true
camel.vault.azure.vaultName = vaultName

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

camel.vault.azure.refreshEnabled=true
camel.vault.azure.refreshPeriod=60000
camel.vault.azure.secrets=Secret
camel.vault.azure.eventhubConnectionString=eventhub_conn_string
camel.vault.azure.blobAccountName=blob_account_name
camel.vault.azure.blobContainerName=blob_container_name
camel.vault.azure.blobAccessKey=blob_access_key
camel.main.context-reload-enabled = true

where camel.vault.azure.refreshEnabled will enable the automatic context reload, camel.vault.azure.refreshPeriod is the interval of time between two different checks for update events and camel.vault.azure.secrets is a regex representing the secrets we want to track for updates.

where camel.vault.azure.eventhubConnectionString is the eventhub connection string to get notification from, camel.vault.azure.blobAccountName, camel.vault.azure.blobContainerName and camel.vault.azure.blobAccessKey are the Azure Storage Blob parameters for the checkpoint store needed by Azure Eventhub.

Note that camel.vault.azure.secrets is not mandatory: if not specified the task responsible for checking updates events will take into accounts or the properties with an azure: prefix.

The only requirement is adding the camel-azure-key-vault JAR to your Camel application.

Automatic Camel context reloading on Secret Refresh while using IBM Secrets Manager

Being able to reload Camel context on a Secret Refresh could be done by specifying the IBM Event Streams credentials combined with the IBM Secrets Manager one (the same used for IBM Secrets Manager Property Function).

With Environment variables:

export CAMEL_VAULT_IBM_TOKEN=token
export CAMEL_VAULT_IBM_SERVICE_URL=serviceUrl
export CAMEL_VAULT_IBM_EVENTSTREAM_BOOTSTRAP_SERVERS=bootstrapServers
export CAMEL_VAULT_IBM_EVENTSTREAM_TOPIC=topic
export CAMEL_VAULT_IBM_EVENTSTREAM_USERNAME=token
export CAMEL_VAULT_IBM_EVENTSTREAM_PASSWORD=password
export CAMEL_VAULT_IBM_EVENTSTREAM_CONSUMER_GROUP_ID=groupId
export CAMEL_VAULT_IBM_EVENTSTREAM_CONSUMER_POLL_TIMEOUT=3000

or as plain Camel main properties:

camel.vault.ibm.token = token
camel.vault.ibm.serviceUrl = serviceUrl
camel.vault.ibm.eventStreamBootstrapServers = bootstrapServers
camel.vault.ibm.eventStreamTopic = topic
camel.vault.ibm.eventStreamUsername = token
camel.vault.ibm.eventStreamPassword = password
camel.vault.ibm.eventStreamGroupId = groupId
camel.vault.ibm.eventStreamConsumerPollTimeout=3000

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

camel.vault.ibm.refreshEnabled=true
camel.vault.ibm.secrets=Secret
camel.main.context-reload-enabled = true

where camel.vault.ibm.refreshEnabled will enable the automatic context reload and camel.vault.ibm.secrets is a regex representing the secrets we want to track for updates.

where camel.vault.ibm.eventStreamBootstrapServers is the comma-separated list of Bootstrap Servers for IBM Event Stream, camel.vault.ibm.eventStreamTopic, camel.vault.ibm.eventStreamUsername, camel.vault.ibm.eventStreamPassword, camel.vault.ibm.eventStreamGroupId and camel.vault.ibm.eventStreamConsumerPollTimeout are the IBM Event Stream parameters for connecting and consuming events related to Secrets.

Note that camel.vault.ibm.secrets is not mandatory: if not specified the task responsible for checking updates events will take into accounts or the properties with an ibm: prefix.

The only requirement is adding the camel-ibm-secrets-manager JAR to your Camel application.

Automatic Camel context reloading on Secret Refresh while using Hashicorp Vault

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:

export CAMEL_VAULT_HASHICORP_TOKEN=token
export CAMEL_VAULT_HASHICORP_HOST=host
export CAMEL_VAULT_HASHICORP_PORT=port
export CAMEL_VAULT_HASHICORP_SCHEME=http/https

or as plain Camel main properties:

camel.vault.hashicorp.token = token
camel.vault.hashicorp.host = host
camel.vault.hashicorp.port = port
camel.vault.hashicorp.scheme = scheme

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

camel.vault.hashicorp.refreshEnabled=true
camel.vault.hashicorp.refreshPeriod=60000
camel.vault.hashicorp.secrets=database,api-keys
camel.main.context-reload-enabled = true

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

For example, to track secrets omsecret/test in the default secret engine and myapp/credentials in a custom kv engine:

camel.vault.hashicorp.secrets=omsecret/test,kv:myapp/credentials

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.

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

How the Refresh Mechanism Works

Unlike cloud-based secret managers (AWS, GCP, Azure) that provide event-driven notifications, Hashicorp Vault does not have a native event notification system for secret changes. Therefore, this implementation uses a polling-based approach:

  1. Metadata Polling: The refresh task periodically queries the Hashicorp Vault metadata endpoint (/v1/<engine>/metadata/<secret>) for each tracked secret.

  2. Version Tracking: It compares the current_version field to detect changes.

  3. Change Detection: When a version change is detected, it triggers a Camel context reload.

  4. Efficiency: Only metadata is queried (not the full secret content), making this approach lightweight.

For example, if a secret named database is updated in Vault:

  • The metadata endpoint returns "current_version": 5

  • On the next check, if current_version changes to 6, a reload is triggered

  • The refresh period (default 60 seconds) determines how quickly changes are detected

This polling approach works with all Hashicorp Vault deployments (on-premise, cloud, enterprise, and open-source) without requiring additional infrastructure.

Back to top