Open rassie opened 3 weeks ago
rassie
commented
2 weeks ago Stumbled upon https://github.com/bitnami/charts/issues/19744 and https://github.com/argoproj/argo-cd/issues/7572, it seems a generic non-Adoptium-specific solution might be in order.
gaeljw
commented
3 days ago 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:
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).
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:
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:
cacertsfile from it to a temporary volume.cacertsusing the existing logic from the entrypoint script ofeclipse-temurin.cacertsfile and an added environment variableJAVA_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 composewith 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
cacertsand 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 thecacertsfile?We'd also need the following steps in Adoptium project: