oscerd opened a new pull request, #29210: URL: https://github.com/apache/camel/pull/29210
Fixes [CAMEL-26279](https://issues.apache.org/jira/browse/CAMEL-26279), found while adding the catalog body types (CAMEL-24961). ## 1. verifySsl and certificatePath are applied **Was:** `CyberArkVaultConfiguration` has `verifySsl` (default `true`) and `certificatePath`, and the vault configuration has `camel.vault.cyberark.verifySsl` and `camel.vault.cyberark.certificatePath` (shown in the SSL Certificate Verification section of the component doc), but `ConjurClientImpl` built its `HttpClient` with the default SSL context of the JVM and used none of them. A Conjur server with a certificate of a private CA could not be used through `certificatePath`, and `verifySsl=false` did nothing. **Now:** `ConjurClientFactory.createSslContext(verifySsl, certificatePath)` builds the SSL context of the client, and the endpoint (from its options) and the CyberArk Conjur Vault Property Function (from the vault configuration) pass it to the client through new factory methods and a new `ConjurClientImpl` constructor. The existing factory methods and constructor stay and use the default SSL context of the JVM. - By default (`verifySsl=true`, no `certificatePath`) the client uses the default SSL context of the JVM, as before. - `certificatePath` is the path of a file with one or more certificates (PEM or DER). They are trusted instead of the default trust store of the JVM, and the host name is still checked. A file that cannot be read, or that has no certificate, fails the start of the endpoint or of the function. - `verifySsl=false` trusts any server: neither the certificate nor the host name is checked. It is done with a trust manager of this client only (an `X509ExtendedTrustManager`, so the JDK does not add its own host name check), not with a JVM-wide setting, and it logs a warning when the client is created. `certificatePath` is not used then. - `verifySsl` has `security = "insecure:ssl"` and `insecureValue = "false"`, as `verifySsl` of camel-ibm-watsonx-ai and `hostnameVerification` of camel-ftp, so the security policy reports `camel.component.cyberark-vault.verifySsl=false`. Both options get `label = "security"`, and their descriptions say what they do. ## 2. The secret version is URL encoded **Was:** the `CamelCyberArkVaultSecretVersion` header was appended to the URL as `"?version=" + version`. A version with `&` or `=` added other query parameters, and one with a space failed with an `IllegalArgumentException` from `URI.create`. **Now:** the version is encoded with `URLEncoder`, as the secret id already is. A numeric version is sent as before. ## 3. getSecret sets the secret only as the body **Was:** `getSecret` set the secret both as the body and in the `CamelCyberArkVaultSecretValue` header. The header then travelled with the message, and a `createSecret` later in the same exchange, which prefers that header over its body, stored the value read earlier instead of its new body (also item 3 of CAMEL-26256). **Now:** `getSecret` sets the secret only as the body, with the `CamelCyberArkVaultSecretId` header as before. `createSecret` still stores the `CamelCyberArkVaultSecretValue` header when the route sets it, as documented. The output body type no longer mentions the header. ## Tests - `CyberArkVaultSslTest` (new) runs an HTTPS server (JDK `HttpsServer`) with a self-signed certificate for `localhost` (EC key, valid for 100 years, made with `keytool`; the keystore and the certificate are new test resources): - with the default trust of the JVM the call fails with an SSL error; - with `certificatePath` set to the server certificate, the call to `https://localhost` succeeds, and the call to `https://127.0.0.1` fails because the host name is still checked; - with `certificatePath` set to another certificate (a CA of the JVM trust store, written to a PEM file), the call fails; - with `verifySsl=false`, the call to `https://127.0.0.1` succeeds; - with a `certificatePath` file that does not exist, the endpoint fails to start; - the CyberArk Conjur Vault Property Function uses the `certificatePath` and the `verifySsl` of the vault configuration. - `ConjurClientSecretVersionTest` (new): a fake Conjur on a JDK `HttpServer` records the raw query: `version=3` for `3`, `version=1%26other%3D2` for `1&other=2`, `version=1+2` for `1 2`, and no query without a version. - `CyberArkVaultProducerTest` (new), with a mocked `ConjurClient`: `getSecret` sets the body and not the `CamelCyberArkVaultSecretValue` header; `getSecret` and then `createSecret` with a new body in the same exchange stores the new body; `createSecret` still stores the header when the route sets it. - `CyberArkVaultProducerIT` now checks that the header is not set after `getSecret`. - Without the change in `src/main`: 9 of the 15 new tests fail. The four SSL tests that need the options (`certificatePath` and `verifySsl=false` on the endpoint, and both on the property function) fail with `PKIX path building failed`, and the endpoint with a missing certificate file starts. The two version tests get `version=1&other=2`, and an `IllegalArgumentException` from `URI.create` for the space. The two producer tests find the old value in the `CamelCyberArkVaultSecretValue` header, and stored by `createSecret`. The 6 that pass are the guards: the default trust, another certificate and the host name check fail with an SSL error before too, a numeric version and no version, and `createSecret` with the header set by the route. - Module: 15 unit tests, 0 failures. The 14 integration tests of the module also pass against a Conjur container, including `CyberArkVaultProducerIT` with its updated header check. ## Docs and generated files - `cyberark-vault-component.adoc`: the SSL Certificate Verification section says what `certificatePath` and `verifySsl` do, that the `camel.vault.cyberark` properties configure the property function while an endpoint uses its own options, and that the security policy reports `verifySsl=false`. Catalog copy updated. - `cyberark-vault.json` regenerated (the label, security marker and descriptions of `verifySsl` and `certificatePath`, and the output body type description), with its catalog copy. - The endpoint and component DSL change (group and description of the two options), and `SecurityUtils` adds `cyberark-vault` to the owners of `verifyssl`. - Upgrade guide entry for 4.24: the two options now apply (and what to do to keep the JVM trust store), the security policy, and the removed header with how to keep it. ## Not changed - `certificatePath` is read as a file system path, as the option name and the doc example say (`/path/to/cert.pem`); the `classpath:` and `file:` prefixes of Camel resources are not supported. Loading it through `ResourceHelper`, as `certificatePath` of camel-elasticsearch-rest-client and camel-solr does, would be a small follow-up if wanted. - The certificates in `certificatePath` replace the default trust store of the JVM rather than being added to it, as `certificatePath` of camel-elasticsearch-rest-client and camel-solr does. - `verifySsl=false` also skips the host name check, so that a test server reached by another name or by its IP address can be used. The JDK HTTP client has no option of its own for that, only a JVM-wide system property, hence the trust manager of the client. - The vault option `camel.vault.cyberark.verifySsl` (in camel-api) does not get the `insecure:ssl` marker here, as that is a core change; the security policy already matches it by name through `verifySsl` of camel-ibm-watsonx-ai. - There are no environment variables for the two settings of the property function, as for the other vault properties that have none; it reads them from the vault configuration also when the credentials come from environment variables. - `createSecret` still prefers the `CamelCyberArkVaultSecretValue` header over the body, as documented with an example. - Backport: `camel-4.22.x` and `camel-4.18.x` have the same code for the three items. Applying `verifySsl` and `certificatePath` there would change the trust of existing deployments in a patch release (an ignored `verifySsl=false` would start trusting any server, and a `certificatePath` would replace the JVM trust store), and adds a security marker; the header removal changes the output. So this stays on main. A private CA can be trusted on those branches through the JVM trust store. The version encoding alone is a plain fix, but Conjur versions are numbers, so it is not worth a port on its own. Main only, as the other fixes of the CAMEL-24961 follow-ups. _Claude Code on behalf of Andrea Cosentino (oscerd)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
