Cool, thanks! I'll speak to the shared cluster support team to see if they can install our CA cert on every box. So we've got that side of authentication sorted - flink can trust that the service is who it says it is.
How about the other way around? Any thoughts on how I could provide a *key*store for the stateful functions job to use while calling remote function services with TLS? The remote function server (undertow in our case) needs to authenticate and authorise statefun based on the latter's cert. Many thanks Fil On Mon, 24 Jan 2022 at 21:25, Igal Shilman <igal.shil...@gmail.com> wrote: > Hello Filip, > > As far as I know SslContextBuilder.forClient() should use the default > trust store, so if you will install your self signed certificate in the > community supported container image this should be picked up[1]. > The following user has reported something similar, and it seems that > they've gone down a similar path [2]. > > Cheers, > Igal. > > [1] https://stackoverflow.com/a/35304873/4405470 > [2] https://lists.apache.org/thread/nxf7yk5ctcvndyygnvx7l34gldn0xgj3 > > > On Mon, Jan 24, 2022 at 7:08 PM Filip Karnicki <filip.karni...@gmail.com> > wrote: > >> Hi All! >> >> I was wondering if there's a way to secure a remote function by requiring >> the client (flink) to use a client cert. Preferably a base64 encoded string >> from the env properties, but that might be asking for a lot :) >> >> I had a look at the code, and NettySharedResources seems to use >> SslContextBuilder.forClient(), and doesn't really seem to deal with setting >> any kind of a keystore >> >> Also, I don't think that setting >> -Djavax.net.ssl.trustStore=path/to/truststore.jks does anything, since I >> keep getting 'unable to find valid certification path to requested target', >> while an exported .pem from my tuststore works fine as a CA in postman >> >> I'm happy to contribute some code if need be, just point me in the right >> direction >> >> Kind regards, >> Fil >> >
