-
-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for custom CA certificates #392
Conversation
Please be sure to sign the ECA. |
Already on it |
As original requestor of the feature, I'm fine with the choice that has been made to replace certs rather than merge because merging can be done beforehand if needed and it's probably better to let the user choose the "merging strategy" (I'm not that familiar with these stuff but I heard that there's several ways to do it). |
@rassie Can we set this to ready for review now? |
From my point of view, of course. I've expected a bit more discussion in terms of TODOs, but I suppose it can be done as part of the review. |
@jerboaa Over to you for the first pass I think :-) |
It's on my list of things to look at but likely not before end of next week. Sorry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems alright to me from a conceptional perspective. Please integrate the test script into the repo and use it from the PR tester workflow as an additional test. Otherwise, I'd defer to @gdams for a review as he's more familiar with the scripting.
I'll try to figure out how that works, but if I have some questions, is there someone specific I could ask, either here or on Adoptium Slack? |
Paging @gdams for input on the test strategy. Thanks! |
@jerboaa so it seems the test is being found and executed, so we've got the infrastructure part right. I'll look over the script error later today or tomorrow. |
It seems the tests need to be in the |
Another fix for JRE/JDK 8 detection. The fix for Windows exclusion is still pending. |
I think this should be it. 🤞 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine to me. Thanks for the contribution!
The code changes LGTM me. I'll ask our (MSFT) infra and security folks to take a look at this as well. Sorry for the hold up but this is pretty critical stuff, more eyes are good :-) |
@jerboaa on the topic of documentation: should I be updating https://github.com/docker-library/docs/blob/master/eclipse-temurin/content.md in some way? |
@rassie Yes that seems suitable. But only once this PR is merged and builds have been produced. Feel free to produce a draft PR there, though. We'd also welcome a blog post here: https://github.com/adoptium/adoptium.net/tree/main/content Thanks! |
This comment was marked as outdated.
This comment was marked as outdated.
@gdams Thanks, fingers crossed! |
@rassie the PMC wishes to pass on thanks for your work on this new feature. We realise that it has been open for a long time, and recognise that it has been well thought through and provides thorough local testing. This is a great new capability for the official Temurin images and as gdams noted, once this has been validated on one Java version we will roll it out to all. Thanks again 👍 |
Will be available after adoptium/containers#392 is merged.
Will be available after adoptium/containers#392 is merged.
Will be available after adoptium/containers#392 is merged.
The upstream entrypoint is `sh` and so loses dotted environment variables, lets prevent that from happening by just skipping it as the `tomcat` images are not reliant on its functionality. See docker-library/docs#2338 and adoptium/containers#392 for info about what it provides. Fixes docker-library#302 which is a recurrence of docker-library#77
This pr broke all images that depends on this. as we have our own entrypoint and are using a low privileged user. thx |
Care to elaborate? What exactly is breaking when you override the entrypoint? I think I've tested that use-case when developing and it worked fine, IIRC, would fix ASAP if I understand the problem correctly. |
We have fixt it but your entryoint.sh is root owned and we can not overwrite it directly as our images are run by a low priv user called container. example: https://github.com/parkervcp/yolks/tree/master/java/11 because the base image is yours and you have some logic in the entryoint of you as we do not overwrite it as we use CMD and coppy in our own entrypoint. when we start are containers it tries to run your entrypoint but it is root owned so it will fail. we got arround it but we just wanted to let you know as not every use for this as a base image will fit everyone. |
Oh, so we have a clash with filenames, i.e. we've introduced
I've tried running In general, thank you for the feedback, is there anything you'd have us do differently with this feature? |
@rassie I would suggest renaming our custom entrypoint.sh script as it's the most likely name to cause conflict? What do you think? |
Hi @rassie - have you any thoughts on this issue posted here? #415 We're running into issues on some of our applications where env variables with a |
Would be one the easier solutions, however it's a breaking change, even though it's only been a couple of weeks. Either way, someone from the project will need to decide how to go on. |
I think that where we've already created a breaking change I'm going to back this out from the upstream images (for now) so we can work on a fix here. |
Backing this out until adoptium/containers#392 has been resolved
From that issue:
I have no problem with changing to |
@gdams Thanks, gives us a bit of time. I'll prepare a PR with moved entrypoint script (somewhere with little chance of name clash) and with |
yes please |
thank you for your fast and grate reesponse, this is what the error is as the container is forced to start as a low prive user called "container" and that file is indeed a naming conflict so it tryes to execute you entrypoint what is root owned or at least conflict with ours as our CMD entry specifyes the same file |
This adds the capability to add custom CA certificates for Java truststore.
This capability used to exist in the old
openjdk
images, but has been removed fromeclipse-temurin
images. This PR adds an entrypoint toeclipse-temurin
images, which adds CA certificates from/certificates
path inside the image to the system certificate store and replaces JRE's truststore with it. This only happens ifUSE_SYSTEM_CA_CERTS
environment variable is set, so by default, no action is taken.Important caveat (needs further discussion!)
This PR deviates from the discussion in #293 in one important aspect. When discussing this feature, I've made an assumption about the inner workings of
openjdk
images which turned out incorrect. I thought that the system certificate store and JRE's truststore used to get merged by theopenjdk
image, which was option c) in our discussion. However, it turns out that the system store used to get converted to truststore format and then replaced JRE's store completely. This is the option b) in the #293 discussion, which we dismissed as non-sensical.While implementing this PR, I've took previously existing process in
openjdk
images as my blueprint, which means, I've actually implemented b) instead of c) and would like to argue in favor of keeping this implementation. I'm fully aware that this decision will need to be discussed further.My arguments in favor are:
openjdk
images used to implement; reinstating that functionality was the whole point of Support the use system cacerts as an option #293openjdk
, so the option to use untampered truststore still exists and is the defaultDifferences from
openjdk
imagesEven though this PR is intended to re-introduce functionality previously available in
openjdk
images, there are important differences in the implementation and usage:openjdk
images added hooks to OS's certificate store update functionality (update-ca-trust
/update-ca-certificates
), but never actually updated the store on image start. This PR makes sure that truststores are updated in the entrypoint if the opt-in variable is setopenjdk
images did not provide a dedicated directory for additional certificates, the user was expected to add them to/usr/share/pki/ca-trust-source/anchors/
or/usr/local/share/ca-certificates/
, depending on the underlying OS. This PR provides a/certificates
directory, which is a stable mount point for CA certificates.Basically, with
openjdk
images it has been necessary to patch the entrypoint to includeupdate-ca-certificates
,eclipse-temurin
images would only require an opt-in environment variable to be set.Documentation
The documentation is missing completely, because I don't know (yet) whether to put it.
Short itemized quick-start guide:
/certificates/
inside the containerUSE_SYSTEM_CA_CERTS
environment variable to any value.Testing
This patch has been tested semi-manually with the following Bash script executed from the repository root
This scripts generates a certificate, builds all images and tests that the entrypoint does not fail:
The script checks that both normal execution of any command (in this case
date
) is possible and that the certificate is in the JRE's truststore when it's expected to be there (when the certificate is mounted and opt-in is set).The following output is produced by the test script, reporting a full success:
OS support
This PR explicitely excludes Windows support, mostly because I lack expertise and an actual Windows installation to develop and test it. Additionally, it's unclear whether
openjdk
included CA certificate support for Windows.TODO / Help needed
I need some guidance of the following items:
Fixes: #293