Create a companion container for CA certificate handling

[rassie]

This is a spin-off of #538, originally posted there; created a new issue at request for easier discussion.

CC: @gaeljw you've opened #293 and also #464, I'd like to have your input whether this would work in your environment.

I've been writing a comment addressing @tianon's point about scope creep and have instead thought of a way to maybe keep multiple sides happy, while reducing pain points, in particular:

• People feeling the scope creep and maintenance burden
• People not liking the entrypoint requirement
• People wanting to inject CA certificates into JRE trust stores.

The idea is to use a companion container image, maintained either inside or outside of Adoptium project, which would contain most of the logic in the current entrypoint and could be used as an init container.

It would work somewhat like this:

1. Start you main container as an init container, copy the cacerts file from it to a temporary volume.
2. Start the companion image as a second init-container with your custom certificates and temporary volume from step 1 mounted; combine both to a new cacerts using the existing logic from the entrypoint script of eclipse-temurin.
3. Start your main container with an added volume mount containing the new cacerts file and an added environment variable JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStore=/volume/cacerts -Djavax.net.ssl.trustStorePassword=changeit.

This would probably make the Kubernetes camp happy, since it directly maps onto Kubernetes way of doing things. Docker camp would need something like docker compose with service_completed_successfully, but this is probably still manageable in a similar way.

If this companion image were to be maintained inside the Adoptium project, we might get away with just including the default cacerts and thus only needing one init container instead of two. No idea how dependant this is on the actual JRE version, maybe there is some common source for the cacerts file?

We'd also need the following steps in Adoptium project:

• Freeze and deprecate current entrypoint-based certificate implementation, add a deprecation warning
• Document the recommended implementation process
• At some point in the future: remove current certificate functionality, possibly remove the entrypoint altogether.

[rassie]

Stumbled upon bitnami/charts#19744 and argoproj/argo-cd#7572, it seems a generic non-Adoptium-specific solution might be in order.

[gaeljw]

Hello,

Sorry for the late answer, this was on my radar but not a top prio :) Here are my first thoughts but I may need more time to think about it.

My first reaction would be that I dislike the idea of needing an init container (or two) for the functionality. Why? Mainly because it's "more complex" than a single container. It requires more work in the Kubernetes manifests and may frighten people looking at the manifests wondering why such a setup is required.

On top of that, I wonder if init containers would affect overall startup times and/or make resources (cpu/memory) more difficult to manage?

---

To be honest, even though I'm the one who opened the 2 original issues #293 and #464, I don't use the feature.

I've 2 use cases:

• (A) mounting CA certificate at runtime in a Kubernetes context
• (B) having ready-to-use custom JDK images for building Java apps that natively include a CA certificate, these images are not used for runtime though, only build time

For (A), I'm using trust-manager and mounting the certificates automatically in my containers (thanks to a generic Helm chart that we use for our JVM apps) to /certificates + requiring people to include -Djavax.net.ssl.trustStore=/certificates/bundle.jks as part of their JVM flags. I didn't have yet a case where I would have needed the certificate to be trusted at the OS level, the containers are only running a JVM ; and for other apps (Python or JS), a custom setup is necessary anyway so that I wouldn't benefit from a "one-fits-all" approach by having the certificate trusted at OS level.

For (B), I'm still using a custom update-java-ca-certs.sh script like this:

FROM eclipse-temurin:21-jdk-jammy

COPY update-java-ca-certs.sh .
RUN chmod +x update-java-ca-certs.sh

RUN curl -fL https://cert-repo.mycompany.net/ca.crt -o /usr/local/share/ca-certificates/mycompany.crt && \
  /usr/sbin/update-ca-certificates && \
  ./update-java-ca-certs.sh && \
  rm update-java-ca-certs.sh

(This image is re-built regularly to have the latest certificate always included).