Background
Here I assume that your application being deployed to Kubernetes is connecting to an external server protected by its server certificate outside Kubernetes. For example, like the case in this article.
Inasmuch as can be seen in the link above, there are really multiple ways to resolve this. However, note the methods explained in the article are not really applicable to Java as-is, because Java doesn't make use of the system CA cert store from the OS but uses its own truststore:
Instead of using the windows certificate store it uses its own implementation. Java certificates are stored in a file called cacerts
located at C:\Program Files (x86)\Java\jre1.x.x_xxx\lib\security\
Because you said you successfully used keytool locally, I assume you are already aware of this Java behavior and where your server certificate should be imported into–that is, into the JRE's default cacerts
file under the JRE directory (unless you use some system property to tell the JVM to find a CA truststore at a different location). Since you said you made it work locally, theoretically you can follow the same and it should work on Kubernetes too.
Embedding cacerts
at build time
One straightforward way is to bake your cert into your image at image build time (as you hinted with the Dockerfile
approach). For this purpose, you can use Jib's <extraDirectories>
feature to copy arbitrary files into an image (usage: Maven / Gradle). Just prepare a new cacerts
file and place it into the JRE's default location in the image.
Supplying cacerts
at runtime
If you don't like the idea of baking a cert into the image but rather want to supply it at runtime, I believe you can basically follow the last method described in the article I linked above (although for Java, you should put cacerts
instead, of course). I am not a Kubernetes expert in this domain and unsure if Kubrenetes provides another dedicated solution, but the method in the article seems reasonable and should work.
For container runtimes other than Kubernetes, all of them will have their own way of supplying files or attaching volumes at runtime, so you should be able to achieve the same goal.
UPDATE: on many Linux distros, often <JRE>/lib/security/cacerts
is a symlink to /etc/ssl/certs/java/cacerts
, so you may opt to update the latter instead of the former.
# ls -l /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts
lrwxrwxrwx 1 root root 27 Jan 1 1970 /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -> /etc/ssl/certs/java/cacerts