Hi Fil, If I understand correctly, you are looking for TLS client authentication, i.e. the remote function needs to authenticate the request that is coming from the StateFun runtime. This is indeed not yet supported as it wasn't required by the community. I'd be happy to create an issue and assign you to work on that if you are still interested!
Cheers, Igal. On Mon, Jan 24, 2022 at 11:32 PM Filip Karnicki <filip.karni...@gmail.com> wrote: > 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 >>> >>
