[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/5966 This PR is subsumed by #6326 ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/5966 @EronWright Just saw this - I have concurrently reworked this PR into #6326 which does things more cleanly. I would like to get that PR in for 1.6 (got many users asking for this). I would be happy if you want to build on top of that for the next steps... ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user EronWright commented on the issue: https://github.com/apache/flink/pull/5966 @StephanEwen I would like to work on this issue, building on your PR, would that be OK? ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/5966 I would move ahead with this PR as follows: - Separate internal and external SSL config - Activate SSL client auth for akka, netty, and blob server (pure internal communication) Let's discuss external connectivity on FLIP-26 ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user EronWright commented on the issue: https://github.com/apache/flink/pull/5966 To be honest I don't see a great need to support anything other than a single trusted certificate for internal communication.We could easily build some conveniences around that, like generating a certificate upon cluster startup with an truststore containing only that certificate. I see no need to perform hostname verification because the truststore is constrained. One drawback is that the queryable state interface is practically inaccessible because the cluster certificate is likely unknown to the client. Regarding external connectivity, I don't think that mutual SSL is universally applicable, and I explore some options in FLIP-26. ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/5966 I agree, we need different key/truststores for the internal/external connectivity. This PR was meant as a step in that direction, separating at least within the SSL Utils the internal and external context setup. In your thinking, is there ever a case for a different internal authentication method than "single trusted certificate"? What if were not tied to akka? (Side note: I think for internal communication, 'authentication is authorization' is probably reasonable, because the are no different users/roles for internal communication). Would you assume that internally, we never do hostname verification? ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user EronWright commented on the issue: https://github.com/apache/flink/pull/5966 This looks great but let's please separate the intra-cluster SSL configuration options from the external-cluster options. In particular, the web/API endpoints should be governed by a different keystore and truststore than are the internal endpoints. Likewise, the "hostname verification" option should pertain only to external connectivity. My rationale is that: 1. the truststore to be used for internal connectivity must be highly restrictive; it should never be the system truststore. Meanwhile, the truststore for external connectivity (e.g. from the Flink client) should typically be the system truststore. 2. The certificate to be used for internal connectivity may simply be a generated certificate. Meanwhile, the certificate for external connectivity should be obtained from a cluster CA. For example, in K8s one might expect a cert obtained from the cluster CA and with a CN corresponding to a Service resource (`flink.default.svc.cluster.local`). The whole issue of using a restrictive truststore for internal connectivity has been discussed on various Akka forums, for example [this PR](https://github.com/akka/akka/pull/23568#issuecomment-331919364).Keep in mind that Akka has no authorization layer; any authenticated client is considered authorized. Therefore, a liberal truststore (such as the system truststore) would present an extremely low barrier of entry since public SSL certs are easy to get. ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user GJL commented on the issue: https://github.com/apache/flink/pull/5966 This is relevant http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Discuss-FLIP-26-SSL-Mutual-Authentication-td22188.html ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user GJL commented on the issue: https://github.com/apache/flink/pull/5966 I will take a look at this later today. ---
[GitHub] flink issue #5966: [FLINK-9312] [security] Add mutual authentication for RPC...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/5966 @EronWright This might be interesting to you as well ---
