FYI: The 1.6 docs reflect the setup where internal and external SSL are
separately configured, and where internal SSL uses client authentication.
https://ci.apache.org/projects/flink/flink-docs-release-1.6/ops/security-ssl.html
On Mon, Aug 13, 2018 at 8:54 AM, Stephan Ewen wrote:
> Sounds good,
Sounds good, Eron!
Please go ahead...
On Sat, Jul 28, 2018 at 1:33 AM, Eron Wright wrote:
> As an update to this thread, Stephan opted to split the internal/external
> configuration (by providing overrides for a common SSL configuration):
> https://github.com/apache/flink/pull/6326
>
> Note th
As an update to this thread, Stephan opted to split the internal/external
configuration (by providing overrides for a common SSL configuration):
https://github.com/apache/flink/pull/6326
Note that Akka doesn't support hostname verification in its 'classic'
remoting implementation (though the new
Throwing in some more food for thought:
An alternative to the above proposed separation of internal and external
SSL would be the following:
- We separate channel encryption and authentication
- We use one common SSL layer (internal and external) that is in both
cases only responsible for est
Thank you for bringing this proposal up. It looks very good and we seem to
be thinking along very similar lines.
Below are some comments and thoughts on the FLIP.
*Internal vs. External Connectivity*
That is a very helpful distinction, let's build on that.
- I would suggest to treat eventuall
Hello,
Given that some SSL enhancement bugs have been posted lately, I took some
time to revise FLIP-26 which explores how to harden both external and
internal communication.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80453255
Some recent related issues:
- FLINK-9312 - mutu
