Hi Gabor – thank you for the prompt reply! I appreciate that building a new Flink image means the Dockerfile would allow me to merge certs into the JVM truststore at build time.
However, the reason for the question is that our company (IBM) has a monthly release cycle which includes new Flink images (maybe due to Java version change, dependency change etc.) I would prefer that all our customers do not have to re-build Flink images each month to add in the external certificates. If this was something the operator supported, they could update to new versions without needing to build a new image each time. In addition, it would also mean that in the case of certificate expiry, you would just update the single k8s secret and then stop/resume clusters for the new certificates to be picked up. I hope that clarifies the usecase? -- Nic Townsend IBM Event Processing Senior Engineer / Technical Lead Slack: @nictownsend From: Gabor Somogyi <gabor.g.somo...@gmail.com> Date: Thursday, 19 December 2024 at 11:07 To: dev@flink.apache.org <dev@flink.apache.org> Subject: [EXTERNAL] Re: Java truststores Hi Nic, Not sure I understand all of the road blockers but truststore is normally not per application but per company/org which is relatively static (or at least not short lived). Keystores are normally propagated through volume mounts. Is it not possible to import the truststore into the JVM truststore[1] ? Such can be done during docker image creation... [1] https://connect2id.com/blog/importing-ca-root-cert-into-jvm-trust-store BR, G On Thu, Dec 19, 2024 at 11:43 AM Nic Townsend <nictowns...@uk.ibm.com> wrote: > Hi, I have a proposal for a Flink operator change – but I’m unsure whether > it’s a) valuable, and b) large enough for a FLIP vs a Jira issue. > > Scenario: > > * I am using a selection of connectors that will communicate via TLS > * I would like to be able to connect to both internal and external > services (i.e some use company issued certificates, others are signed by > public authorities) > * I don’t want to have to configure each connector with PEM > certificates (and then edit the program whenever a certificate expires) > > The problem is that all I believe I can do is override the Flink JVM > truststore to point to a truststore with the internal CA certificates: > > env.java.opts.taskmanager: >- > -Djavax.net.ssl.trustStore=/certs/truststore.<keystore-extension> > -Djavax.net.ssl.trustStorePassword=<chosen password> > env.java.opts.jobmanager: >- > -Djavax.net.ssl.trustStore=/certs/truststore.<keystore-extension> > -Djavax.net.ssl.trustStorePassword=<chosen password> > > The problem here is that it overrides the default cacerts truststore in > Java – so I cannot connect to externally signed endpoints. > > I know that I can merge cacerts and my truststore into a new truststore as > a manual process. But it means that I have to remember to extract the > cacerts every time I have a minor java change. > > Proposed scenario: > > * New property on the CR for a secret containing an “external > truststore” (possibly an “external keystore” as well for MTLS) > * The flink operator deploys Flink with an init container and mounts > the secrets > * The init container then combines the default cacerts on the Flink > job/task manager with the “external truststore” and supplies that to the > Flink runtime > > This means that you can enable connecting to both internal and externally > signed endpoints from a Flink job. > > Thoughts as to whether this is big enough for a FLIP (if valuable)? > > -- > > Nic Townsend > IBM Event Processing > Senior Engineer / Technical Lead > > Slack: @nictownsend > > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 > Registered office: Building C, IBM Hursley Office, Hursley Park Road, > Winchester, Hampshire SO21 2JN > Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
