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.

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 are:

Payload Security

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

The dataformats 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.

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:

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 in the following way by using aws: as prefix in the {{ }} syntax:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{aws:route}}"/>
    </route>
</camelContext>

Where route will be the name of the secret stored in the AWS Secrets Manager Service.

You could specify a default value in case the secret is not present on AWS Secret Manager:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{aws:route:default}}"/>
    </route>
</camelContext>

In this case, if the secret doesn’t exist, the property will fallback 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:

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

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{aws:database#username}}"/>
    </route>
</camelContext>

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 AWS Secret Manager:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{aws:database#username:admin}}"/>
    </route>
</camelContext>

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

For the moment we are not considering the rotation function if any are applied, but it is in the work to be done.

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.aws.projectId = region

At this point you’ll be able to reference a property in the following way by using gcp: as prefix in the {{ }} syntax:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{gcp:route}}"/>
    </route>
</camelContext>

Where route will be the name of the secret stored in the GCP Secret Manager Service.

You could specify a default value in case the secret is not present on GCP Secret Manager:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{gcp:route:default}}"/>
    </route>
</camelContext>

In this case, if the secret doesn’t exist, the property will fallback 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:

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

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{gcp:database#username}}"/>
    </route>
</camelContext>

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 GCP Secret Manager:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{gcp:database#username:admin}}"/>
    </route>
</camelContext>

In this case, if the secret doesn’t exist or the secret exists, but the username field is not part of the secret, the property will fallback to "admin" as value.

For the moment we are not considering the rotation function if any are applied, but it is in the work to be done.

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 in the following way:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{azure:route}}"/>
    </route>
</camelContext>

Where route will be the name of the secret stored in the Azure Key Vault Service.

You could specify a default value in case the secret is not present on Azure Key Vault Service:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{azure:route:default}}"/>
    </route>
</camelContext>

In this case, if the secret doesn’t exist, the property will fallback 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:

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

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{azure:database#username}}"/>
    </route>
</camelContext>

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 Azure Key Vault:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{azure:database#username:admin}}"/>
    </route>
</camelContext>

In this case, if the secret doesn’t exist or the secret exists, but the username field is not part of the secret, the property will fallback to "admin" as value.

For the moment we are not considering the rotation function if any are applied, but it is in the work to be done.

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

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{hashicorp:secret:route}}"/>
    </route>
</camelContext>

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:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{hashicorp:secret:route:default}}"/>
    </route>
</camelContext>

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:

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

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{hashicorp:secret:database#username}}"/>
    </route>
</camelContext>

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:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{hashicorp:secret:database#username:admin}}"/>
    </route>
</camelContext>

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:

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{hashicorp:secret:route@2}}"/>
    </route>
</camelContext>

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

<camelContext>
    <route>
        <from uri="direct:start"/>
        <to uri="{{hashicorp:route:default@2}}"/>
    </route>
</camelContext>

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).

<camelContext>
    <route>
        <from uri="direct:start"/>
        <log message="Username is {{hashicorp:secret:database#username:admin@2}}"/>
    </route>
</camelContext>

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).

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 a 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.

Back to top