I have an containerized JVM application (multiple actually) running on kubernetes, which needs to trust additional custom/private CAs (which are not known beforehand, the application will be deployed in multiple unrelated data-centers that have their own PKI).
The cacerts
in the base image are not writable at runtime.
Currently I see these options:
- do not provide an option to modify cacerts, force the DCs to manage & inject their own
cacert
files via container volumes. - make
cacerts
file writeable at runtime and modify cacerts in entrypoint - do not use JDK TLS - set truststore at "client" level (e.g. CXF)
- ...?
Under the assumption the DCs will not run JVM apps only, they will not like to manage cacerts themselves, because cacerts
is specific to JVM and they then potentially need to do that for every technology. Thus I do not really like that option.
The second option seems to be a quite pragmatic one - but I suspect that making the cacerts
writable at runtime is a bad practice because an attacker could modify configuration s/he should not be able to.
The third option has it's limitations and intricacies because you need to make each each and every client configurable. (In case of CXF for example fetching the initial WSDL file does not seem to covered by CXF but by the JVM...) But this means if your client is not (properly) configurable this does not work.
Thus I am back at option 2.
My questions would be:
Is it a bad practice to have cacerts
writeable at runtime?
Is there an option I missed that allows injecting (arbitrary) additional CAs into cacerts
without making it writeable at runtime?