feat(trait): add jvm caCert support and propagate mounts to init containers

[pkalsi97]

This PR adds two related features for init container support:

1. Adds the ability to configure custom CA certificates in the JVM trait, enabling integrations to connect to services using TLS with certificates signed by private CAs.
2. Init containers defined via the init-containers trait now automatically receive volume mounts for:
   ConfigMaps mounted via mount.configs
   Secrets mounted viamount.configs
   Resources mounted via mount.resources

Changes:

• Add CACert and CACertMountPath fields to JVM trait spec
• Implement init container to generate JKS truststore from PEM cert
• Configure JVM with javax.net.ssl.trustStore properties
• Use deterministic password to ensure deployment spec stability
• Add unit and E2E tests
• Regenerate CRDs

# Create secret with CA certificate
kubectl create secret generic my-private-ca --from-file=ca.crt=/path/to/ca-certificate.pem

# Run integration with custom CA
kamel run MyRoute.java -t jvm.ca-cert=secret:my-private-ca

# With custom key name in secret
kamel run MyRoute.java -t jvm.ca-cert=secret:my-private-ca/custom-ca.pem

# With custom mount path
kamel run MyRoute.java -t jvm.ca-cert=secret:my-private-ca -t jvm.ca-cert-mount-path=/etc/custom/truststore


# Init container reading mounted configs
kamel run MyRoute.yaml \
  -t mount.configs=configmap:my-config \
  -t init-containers.init-tasks="setup;alpine;cat /etc/camel/conf.d/_configmaps/my-config/app.properties"

Update

Closes
#2820
#6256

[pkalsi97]

@squakez I just noticed #6397.

if you find this implementation good enough, and can expand a little on the requirements of the implementation. I can either work on it in the same PR or raise a separate one.

[squakez]

Thanks for the work. It may work under certain conditions. However, it is breaking a little the encapsulation. I wonder if you could instead moving all that code to the init-container trait instead. The JVM could still hold the variable of ca-secret, in a similar manner of what we did with #6256

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.6% to 51.7% (+0.1%)

[pkalsi97]

@squakez thanks for the feedback, I'll refer the PR and make the necessary changes.

[pkalsi97]

@squakez If you are satisfied with the current implementation, I am more than happy to work for the solution of #6397 here itself. I'll Update the PR title and Description as well.
I have a question, should all mounts be propagated by default, or should it be opt-in?

Just let me know what approach you will prefer ? and shall it be solved in a separate PR.

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.6% to 51.7% (+0.1%)

[squakez]

Great work, thanks!

[squakez]

@squakez If you are satisfied with the current implementation, I am more than happy to work for the solution of #6397 here itself. I'll Update the PR title and Description as well. I have a question, should all mounts be propagated by default, or should it be opt-in?

Just let me know what approach you will prefer ? and shall it be solved in a separate PR.

Yeah, I think it makes sense to have a generic solution for the mounts to be shared among all containers. However, you can certainly work in a separate PR as it best suit to you. Let me know if you're continuing here, so I'll hold before merging this one.

[pkalsi97]

@squakez I'll be working here only. Will follow up shortly with a genric implementation.

[pkalsi97]

@squakez I have made the changes and also added another E2E test to verify working.

[squakez]

Very cool work indeed. Just a little but important security consideration we must address before merging.

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.6% to 51.8% (+0.2%)

[pkalsi97]

@squakez Addresses security concern where password was exposed in command-line arguments. The password is now injected as an environment variable from a user-provided Kubernetes Secret.

[github-actions]

✔️ Unit test coverage report - coverage increased from 50.6% to 50.8% (+0.2%)

[ephemeris-lappis]

Hello.
I've just tested the new feature on release 2.9.0, and it seems to work, but with two new points :

1. The documentation (in API and code) for caCert and caCertPassword mentions secrets and keys, but it seems that expected values for both entries of the trait are a path to the mounted secrets.
2. Only one certificate is added to the generated truststore : IMHO, it's a very limited use case; for my very first tests I've at least 3 certificates (one for common enterprise's server signing CA, and 2 auto-signed local resources). This means that an init container is also needed with its own keytool operations to get a working JVM.
   I've also a third point that I've already commented some time ago about an option to copy the JDK cacert (as it's done for maven) : root CA certificates are needed to validate intermediary certificates in chains.
   Thanks for your answer.

[pkalsi97]

@ephemeris-lappis Thanks for the feedback, I am sorry that a few things got overlooked in this implementation.
Please go ahead and create an issue, and I'll work on:

1. Fixing the documentation to clarify that file paths (not secret refs) are expected
2. Adding support for multiple CA certificates
3. Adding an option to include JDK's default root CAs (DigiCert, Let's Encrypt, etc.) for certificate chain validation
   I'll get this done shortly.

CC: @squakez

[ephemeris-lappis]

Hello @pkalsi97 and @squakez !

Here is a new issue ; #6436.

;)