Now I see, there is no secret management around Flink. You mentioned that it would be good not to bother users with new docker image builds which is fine. * Where would live the logic which can re-obtain the certs? What I mean here that this logic is user specific and not belongs to the operator.
Related the certificate in-memory update: the operator has certificate hot-plug possibility for webhook. Maybe it's worth to consider to add this to Flink too which can eliminate downtime. BR, G On Thu, Dec 19, 2024 at 12:37 PM Nic Townsend <nictowns...@uk.ibm.com> wrote: > 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 >
