Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Quarkus CXF Security Guide for Red Hat build of Apache Camel
Quarkus CXF Security Guide for Red Hat build of Apache Camel provided by Red Hat
Abstract
Preface
Providing feedback on Red Hat build of Apache Camel documentation
To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account.
Procedure
- Click the following link to create ticket
- Enter a brief description of the issue in the Summary.
- Provide a detailed description of the issue or enhancement in the Description. Include a URL to where the issue occurs in the documentation.
- Clicking Submit creates and routes the issue to the appropriate documentation team.
Chapter 1. Quarkus CXF security guide
This chapter provides information about security when working with Quarkus CXF extensions.
1.1. Security guide
The security guide documents various security related aspects of Quarkus CXF:
1.1.1. SSL, TLS and HTTPS
This section documents various use cases related to SSL, TLS and HTTPS.
The sample code snippets used in this section come from the WS-SecurityPolicy integration test in the source tree of Quarkus CXF
1.1.1.1. Client SSL configuration
If your client is going to communicate with a server whose SSL certificate is not trusted by the client’s operating system, then you need to set up a custom trust store for your client.
Tools like openssl or Java keytool are commonly used for creating and maintaining truststores.
We have examples for both tools in the Quarkus CXF source tree:
Once you have prepared the trust store, you need to configure your client to use it.
1.1.1.1.1. Set the client trust store in application.properties
This is the easiest way to set the client trust store. The key role is played by the following properties:
Here is an example:
application.properties
- 1
pkcs12andjksare two commonly used keystore formats. PKCS12 is the default Java keystore format since Java 9. We recommend using PKCS12 rather than JKS, because it offers stronger cryptographic algorithms, it is extensible, standardized, language-neutral and widely supported.- 2
- The referenced
client-truststore.pkcs12file has to be available either in the classpath or in the file system.
1.1.1.2. Server SSL configuration
To make your services available over the HTTPS protocol, you need to set up server keystore in the first place. The server SSL configuration is driven by Vert.x, the HTTP layer of Quarkus. {link-quarkus-docs-base}/http-reference#ssl[Quarkus HTTP guide] provides the information about the configuration options.
Here is a basic example:
application.properties
# Server side SSL quarkus.tls.key-store.p12.path = localhost-keystore.pkcs12 quarkus.tls.key-store.p12.password = localhost-keystore-password quarkus.tls.key-store.p12.alias = localhost quarkus.tls.key-store.p12.alias-password = localhost-keystore-password
# Server side SSL
quarkus.tls.key-store.p12.path = localhost-keystore.pkcs12
quarkus.tls.key-store.p12.password = localhost-keystore-password
quarkus.tls.key-store.p12.alias = localhost
quarkus.tls.key-store.p12.alias-password = localhost-keystore-password1.1.1.3. Mutual TLS (mTLS) authentication
So far, we have explained the simple or single-sided case where only the server proves its identity through an SSL certificate and the client has to be set up to trust that certificate. Mutual TLS authentication goes by letting also the client prove its identity using the same means of public key cryptography.
Hence, for the Mutual TLS (mTLS) authentication, in addition to setting up the server keystore and client truststore as described above, you need to set up the keystore on the client side and the truststore on the server side.
The tools for creating and maintaining the stores are the same and the configuration properties to use are pretty much analogous to the ones used in the Simple TLS case.
The mTLS integration test in the Quarkus CXF source tree can serve as a good starting point.
The keystores and truststores are created with openssl (or alternatively with Java Java keytool)
Here is the application.properties file:
application.properties
1.1.1.4. Enforce SSL through WS-SecurityPolicy
The requirement for the clients to connect through HTTPS can be defined in a policy.
The functionality is provided by quarkus-cxf-rt-ws-security extension.
Here is an example of a policy file:
https-policy.xml
The policy has to be referenced from a service endpoint interface (SEI):
HttpsPolicyHelloService.java
With this setup in place, any request delivered over HTTP will be rejected by the PolicyVerificationInInterceptor:
ERROR [org.apa.cxf.ws.pol.PolicyVerificationInInterceptor] Inbound policy verification failed: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding: TLS is not enabled
...
ERROR [org.apa.cxf.ws.pol.PolicyVerificationInInterceptor] Inbound policy verification failed: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding: TLS is not enabled
...1.1.2. Authentication and authorization
The sample code snippets shown in this section come from the Client and server integration test in the source tree of Quarkus CXF. You may want to use it as a runnable example.
1.1.2.1. Client HTTP basic authentication
Use the following client configuration options provided by quarkus-cxf extension to pass the username and password for HTTP basic authentication:
Here is an example:
application.properties
quarkus.cxf.client.basicAuth.wsdl = http://localhost:${quarkus.http.test-port}/soap/basicAuth?wsdl
quarkus.cxf.client.basicAuth.client-endpoint-url = http://localhost:${quarkus.http.test-port}/soap/basicAuth
quarkus.cxf.client.basicAuth.username = bob
quarkus.cxf.client.basicAuth.password = bob234
quarkus.cxf.client.basicAuth.wsdl = http://localhost:${quarkus.http.test-port}/soap/basicAuth?wsdl
quarkus.cxf.client.basicAuth.client-endpoint-url = http://localhost:${quarkus.http.test-port}/soap/basicAuth
quarkus.cxf.client.basicAuth.username = bob
quarkus.cxf.client.basicAuth.password = bob2341.1.2.1.1. Accessing WSDL protected by basic authentication
By default, the clients created by Quarkus CXF do not send the Authorization header, unless you set the quarkus.cxf.client."client-name".secure-wsdl-access to true:
application.properties
quarkus.cxf.client.basicAuthSecureWsdl.wsdl = http://localhost:${quarkus.http.test-port}/soap/basicAuth?wsdl
quarkus.cxf.client.basicAuthSecureWsdl.client-endpoint-url = http://localhost:${quarkus.http.test-port}/soap/basicAuthSecureWsdl
quarkus.cxf.client.basicAuthSecureWsdl.username = bob
quarkus.cxf.client.basicAuthSecureWsdl.password = ${client-server.bob.password}
quarkus.cxf.client.basicAuthSecureWsdl.secure-wsdl-access = true
quarkus.cxf.client.basicAuthSecureWsdl.wsdl = http://localhost:${quarkus.http.test-port}/soap/basicAuth?wsdl
quarkus.cxf.client.basicAuthSecureWsdl.client-endpoint-url = http://localhost:${quarkus.http.test-port}/soap/basicAuthSecureWsdl
quarkus.cxf.client.basicAuthSecureWsdl.username = bob
quarkus.cxf.client.basicAuthSecureWsdl.password = ${client-server.bob.password}
quarkus.cxf.client.basicAuthSecureWsdl.secure-wsdl-access = true1.1.2.2. Mutual TLS (mTLS) authentication
See the Mutual TLS (mTLS) authentication section in SSL, TLS and HTTPS guide.
1.1.2.3. Securing service endpoints
The server-side authentication and authorization is driven by {link-quarkus-docs-base}/security-overview[Quarkus Security], especially when it comes to
- {link-quarkus-docs-base}/security-authentication-mechanisms[Authentication mechanisms]
- {link-quarkus-docs-base}/security-identity-providers[Identity providers]
- {link-quarkus-docs-base}/security-authorize-web-endpoints-reference[Role-based access control (RBAC)]
There is a basic example in our Client and server integration test. Its key parts are:
-
io.quarkus:quarkus-elytron-security-properties-filedependency as an Identity provider Basic authentication enabled and users with their roles configured in
application.properties:application.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Role-based access control enfoced via
@RolesAllowedannotation:
BasicAuthHelloServiceImpl.java
1.1.3. Authentication enforced by WS-SecurityPolicy
You can enforce authentication through WS-SecurityPolicy, instead of Mutual TLS and Basic HTTP authentication for clients and services.
To enforce authentication through WS-SecurityPolicy, follow these steps:
- Add a supporting tokens policy to an endpoint in the WSDL contract.
-
On the server side, implement an authentication callback handler and associate it with the endpoint in
application.propertiesor via environment variables. Credentials received from clients are authenticated by the callback handler. -
On the client side, provide credentials through either configuration in
application.propertiesor environment variables. Alternatively, you can implement an authentication callback handler to pass the credentials.
1.1.3.1. Specifying an Authentication Policy
If you want to enforce authentication on a service endpoint, associate a supporting tokens policy assertion with the relevant endpoint binding and specify one or more token assertions under it.
There are several different kinds of supporting tokens policy assertions, whose XML element names all end with SupportingTokens (for example, SupportingTokens, SignedSupportingTokens, and so on). For a complete list, see the Supporting Tokens section of the WS-SecurityPolicy specification.
1.1.3.2. UsernameToken policy assertion example
The sample code snippets used in this section come from the WS-SecurityPolicy integration test in the source tree of Quarkus CXF. You may want to use it as a runnable example.
The following listing shows an example of a policy that requires a WS-Security UsernameToken (which contains username/password credentials) to be included in the security header.
username-token-policy.xml
There are two ways how you can associate this policy file with a service endpoint:
Reference the policy on the Service Endpoint Interface (SEI) like this:
UsernameTokenPolicyHelloService.java
@WebService(serviceName = "UsernameTokenPolicyHelloService") @Policy(placement = Policy.Placement.BINDING, uri = "username-token-policy.xml") public interface UsernameTokenPolicyHelloService extends AbstractHelloService { ... }@WebService(serviceName = "UsernameTokenPolicyHelloService") @Policy(placement = Policy.Placement.BINDING, uri = "username-token-policy.xml") public interface UsernameTokenPolicyHelloService extends AbstractHelloService { ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Include the policy in your WSDL contract and reference it via
PolicyReferenceelement.
When you have the policy in place, configure the credentials on the service endpoint and the client:
application.properties
In the above listing, usernameTokenPasswordCallback is a name of a @jakarta.inject.Named bean implementing javax.security.auth.callback.CallbackHandler. Quarkus CXF will lookup a bean with this name in the CDI container.
Here is an example implementation of the bean:
UsernameTokenPasswordCallback.java
To test the whole setup, you can create a simple {link-quarkus-docs-base}/getting-started-testing[@QuarkusTest]:
UsernameTokenTest.java
When running the test via mvn test -Dtest=UsernameTokenTest, you should see a SOAP message being logged with a Security header containing Username and Password:
Log output of the UsernameTokenTest
1.1.3.3. SAML v1 and v2 policy assertion examples
The WS-SecurityPolicy integration test contains also analogous examples with SAML v1 and SAML v2 assertions.
Chapter 2. Camel Security
This chapter provides information about Camel route security options.
2.1. Camel security overview
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.
2.2. 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.
2.3. 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:
2.4. 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.
2.5. 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.
2.5.1. Configuration Security using Vaults
The following Vaults are supported by Camel:
2.5.1.1. 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
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
camel.vault.aws.accessKey = accessKey
camel.vault.aws.secretKey = secretKey
camel.vault.aws.region = regionIf 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
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
camel.vault.aws.defaultCredentialsProvider = true
camel.vault.aws.region = regionIt 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
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
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:
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:
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:
You’re able to do get single secret value in your route, 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 AWS Secret Manager:
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.
2.5.1.2. Using Google Secret Manager 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
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
camel.vault.gcp.serviceAccountKey = accessKey
camel.vault.gcp.projectId = secretKeyIf 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
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
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:
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:
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:
You’re able to do get single secret value in your route, 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 GCP Secret Manager:
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)
2.5.1.3. 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
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
camel.vault.azure.tenantId = accessKey
camel.vault.azure.clientId = clientId
camel.vault.azure.clientSecret = clientSecret
camel.vault.azure.vaultName = vaultNameOr 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
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
camel.vault.azure.azureIdentityEnabled = true
camel.vault.azure.vaultName = vaultNameAt 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 Azure Key Vault Service.
You could specify a default value in case the secret is not present on Azure Key Vault Service:
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:
You’re able to do get single secret value in your route, 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 Azure Key Vault:
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.
2.5.1.4. 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
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
camel.vault.hashicorp.token = token
camel.vault.hashicorp.host = host
camel.vault.hashicorp.port = port
camel.vault.hashicorp.scheme = schemeAt 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).
2.5.1.5. 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
export $CAMEL_VAULT_AWS_USE_DEFAULT_CREDENTIALS_PROVIDER=accessKey
export $CAMEL_VAULT_AWS_REGION=regionor as plain Camel main properties:
camel.vault.aws.useDefaultCredentialProvider = true camel.vault.aws.region = region
camel.vault.aws.useDefaultCredentialProvider = true
camel.vault.aws.region = regionOr 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
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.
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 Couldtrail trail
- an AWS SQS Queue
- an Eventbridge rule of the following kind
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>\"}}}]}"
}
{
"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
aws sqs set-queue-attributes --queue-url <queue_url> --attributes file://policy.jsonwhere 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:
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.
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
export $CAMEL_VAULT_GCP_USE_DEFAULT_INSTANCE=true
export $CAMEL_VAULT_GCP_PROJECT_ID=projectIdor as plain Camel main properties:
camel.vault.gcp.useDefaultInstance = true camel.vault.aws.projectId = projectId
camel.vault.gcp.useDefaultInstance = true
camel.vault.aws.projectId = projectIdOr 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:
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)
2.5.1.8. 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
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=vaultNameor 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
camel.vault.azure.tenantId = accessKey
camel.vault.azure.clientId = clientId
camel.vault.azure.clientSecret = clientSecret
camel.vault.azure.vaultName = vaultNameIf 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
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
camel.vault.azure.azureIdentityEnabled = true
camel.vault.azure.vaultName = vaultNameTo enable the automatic refresh you’ll need additional properties to set:
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.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}