Fix #2791: expose sslContextParameters on the opensearch Kamelets

[oscerd]

Fixes #2791.

The issue offers two approaches. The first — mapping the component's SSL parameters onto Kamelet properties — turns out not to be available, so this implements the second.

Why not scalar properties

camel-opensearch has no scalar TLS options to map. Its entire TLS surface is:

[componentProperties] enableSSL:                     boolean
[componentProperties] sslContextParameters:          org.apache.camel.support.jsse.SSLContextParameters
[componentProperties] useGlobalSslContextParameters: boolean
[properties]          enableSSL:                     boolean
[properties]          certificatePath:               String
[properties]          sslContextParameters:          org.apache.camel.support.jsse.SSLContextParameters
[properties]          hostnameVerifier:              javax.net.ssl.HostnameVerifier

There is nothing for cipher suites, TLS version, keystores or hostname verification to bind to individually — all of it lives inside SSLContextParameters. So the Kamelet has to hand over that object one way or another.

Why not build the bean in the template

The catalog's usual idiom would be to construct it in template.beans from scalar properties, the way aws-redshift-sink builds its BasicDataSource. That does not work here, for a reason worth recording:

• Kamelet beans are created unconditionally — there is no way to build one only when the operator supplies keystore properties.
• sslContextParameters takes precedence over certificatePath (the component says so explicitly).

Together those mean an always-present SSLContextParameters bean would silently disable the existing certificate property for every current user, whether or not they wanted advanced TLS. That is a regression I am not willing to ship for an enhancement.

What this does

One optional property per Kamelet, pointing at a bean the operator registers:

      sslContextParameters:
        title: SSL Context Parameters
        description: >-
          Reference to a registry bean of type org.apache.camel.support.jsse.SSLContextParameters,
          written as "#bean:myBeanName". ...
        type: string

            certificatePath: "base64:{{?certificate}}"
            sslContextParameters: "{{?sslContextParameters}}"

Passed with {{?...}}, so when unset the parameter is omitted from the endpoint URI entirely and nothing changes for existing users. When set, it unlocks everything the issue asked for at once — mTLS client keystore, custom trust store, TLS protocol version, cipher suites — because those are all fields of SSLContextParameters.

Verification

script/validator reports no errors; mvn clean install passes with tests from the repository root.

Behaviour checked against the real component, with both paths in a single run:

Routes startup (total:2 started:2 kamelets:2)

• route 1, sslContextParameters: "#bean:mySsl" — the endpoint resolves the registry bean and connects over https, failing only with connection refused since there is no cluster on localhost. An unresolvable bean or a rejected option would have failed at startup instead.
• route 2, property unset — starts unaffected, confirming the opt-out path is untouched.

One thing for reviewers to weigh

This is the catalog's first user-supplied bean reference. Every existing #bean:{{...}} in the catalog (aws-redshift-sink, databricks-*, avro-*-action, the kafka batch sources) points at a template-local bean the Kamelet itself declares. Here the bean comes from the operator's registry instead.

I think that is the right trade for this case, given the two constraints above, and it is how Camel models the option. But it is a genuine pattern decision rather than a mechanical change, so if you would rather the catalog not grow that surface I am happy to close this and instead document in the Kamelet description that advanced TLS requires a custom integration.

hostnameVerifier is the other bean-typed option on this component. I left it out deliberately — it is separable, and one new pattern per PR is enough to judge.

---

Claude Code on behalf of Andrea Cosentino