Security
Camel offers several forms & levels of security capabilities that can be utilized 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.
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 automatic decrypted by Camel using:
Camel also support 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
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 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 fallback to "admin" as value.
For the moment we are not considering the rotation function, if any will be 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 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 will be 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
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 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 will be 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_ENGINE=secretKey
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.engine = engine
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:route}}"/>
</route>
</camelContext>
Where route will be the name of the secret stored in the Hashicorp Vault instance.
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: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 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 {{hashicorp: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:
<camelContext>
<route>
<from uri="direct:start"/>
<log message="Username is {{hashicorp: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.
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:route@2}}"/>
</route>
</camelContext>
This approach will return the RAW route secret with version '2'.
<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.
<camelContext>
<route>
<from uri="direct:start"/>
<log message="Username is {{hashicorp: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.
The only requirement is adding the camel-hashicorp-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 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 while make use of the notification system related to Google Secret Manager: through this feature, every secret could be associated to one up to ten Google Pubsub Topics. These topics will receive events related to 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
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.