Alternatively there would also be an option c) only support mutual auth for Akka 2.4+ if the backport is unrealistic to do
But this of course would break security for Scala 2.10. On the other hand people are already using Flink without this feature. Cheers, Till On Wed, Aug 2, 2017 at 7:21 PM, Eron Wright <eronwri...@gmail.com> wrote: > Thanks Till and Aljoscha for the feedback. > > Seems there are two ways to proceed here, if we accept mutual SSL as the > basis. > > a) Backport mutual-auth support from Akka 2.4 to Flakka. > b) Drop support for Scala 2.10 (FLINK-?), move to Akka 2.4 (FLINK-3662). > > Let's assume (a) for now. > > > > On Tue, Aug 1, 2017 at 3:05 PM, Till Rohrmann <trohrm...@apache.org> > wrote: > > > Dropping Java 7 alone is not enough to move to Akka 2.4+. For that we > need > > at least Scala 2.11. > > > > Cheers, > > Till > > > > On Tue, Aug 1, 2017 at 4:22 PM, Aljoscha Krettek <aljos...@apache.org> > > wrote: > > > > > Hi Eron, > > > > > > I think after Dropping support for Java 7 we will move to Akka 2.4+, so > > we > > > should be good there. I think quite some users should find a (more) > > secure > > > Flink interesting. > > > > > > Best, > > > Aljoscha > > > > On 24. Jul 2017, at 03:11, Eron Wright <eronwri...@gmail.com> wrote: > > > > > > > > Hello, now might be a good time to revisit an important enhancement > to > > > > Flink security, so-called service authorization. This means the > > > hardening > > > > of a Flink cluster against unauthorized use with some sort of > > > > authentication and authorization scheme. Today, Flink relies > entirely > > > on > > > > network isolation to protect itself from unauthorized job submission > > and > > > > control, and to protect the secrets contained within a Flink cluster. > > > > This is a problem in multi-user environments like YARN/Mesos/K8. > > > > > > > > Last fall, an effort was made to implement service authorization but > > the > > > PR > > > > was ultimately rejected. The idea was to add a simple secret key to > > all > > > > network communication between the client, JM, and TM. Akka itself > has > > > > such a feature which formed the basis of the solution. There are > > > usability > > > > challenges with this solution, including a dependency on SSL. > > > > > > > > Since then, the situation has evolved somewhat, and the use of SSL > > mutual > > > > authentication is more viable. Mutual auth is supported in Akka > > 2.4.12+ > > > > (or could be backported to Flakka). My proposal is: > > > > > > > > 1. Upgrade Akka or backport the functionality to Flakka (see commit > > > > 5d03902c5ec3212cd28f26c9b3ef7c3b628b9451). > > > > 2. Implement SSL on any endpoint that doesn't yet support it (e.g. > > > > queryable state). > > > > 3. Enable mutual auth in Akka and implement it on non-Akka endpoints. > > > > 4. Implement a simple authorization layer that accepts any > > authenticated > > > > connection. > > > > 5. (stretch) generate and store a certificate automatically in YARN > > mode. > > > > 6. (stretch) Develop an alternate authentication method for the Web > UI. > > > > > > > > Are folks interested in this capability? Thoughts on the use of SSL > > > mutual > > > > auth versus something else? Thanks! > > > > > > > > -Eron > > > > > > > > >
