Hi Till, Since I'm working in security area 10+ years let me share my thought. I would like to emphasise there are experts better than me but I have some basics. The discussion is open and not trying to tell alone things...
> I mean if an attacker can get access to one of the machines, then it should also be possible to obtain the right Kerberos token. Not necessarily. For example if one gets access to a specific user's credentials then it's not possible to compromise other user's jobs, data, etc... Security is like an onion, the more layers has been added the more time an attacker needs to proceed. At the end of the day if one is in, then most probably can find the way but this time is normally enough to sysadmins or security experts to close down the system and minimize the damage. The other thing is that all tokens has a timeout and if the token is invalid then the attacker can't proceed further. > Is Kerberos also the standard authentication protocol for Kubernetes deployments? Kerberos is an industry standard which is cloud/deployment agnostic and it can be used in any deployments including k8s. The main intention is to use kerberos in k8s deployments too since we're going this direction as well. Please see how Spark does this: https://spark.apache.org/docs/latest/security.html#secure-interaction-with-kubernetes Last but not least the most important reason to add at least one strong authentication is that we have users who has hard requirements on this. They're doing security audits and if they fail then it's deal breaking. That is why we have added kerberos at the first place. Unfortunately we can't name them in this public list, however the customers who specifically asked for this were mainly in the banking and telco sector. BR, G On Thu, Jun 3, 2021 at 9:20 AM Till Rohrmann <trohrm...@apache.org> wrote: > Thanks for updating the document Márton. Why is it that banks will > consider it more secure if Flink comes with Kerberos authentication > (assuming a properly secured setup)? I mean if an attacker can get access > to one of the machines, then it should also be possible to obtain the right > Kerberos token. > > I am not an authentication expert and that's why I wanted to ask what are > other authentication protocols other than Kerberos? Why did we select > Kerberos and not any other authentication protocol? Maybe you can list the > pros and cons for the different protocols. Is Kerberos also the standard > authentication protocol for Kubernetes deployments? If not, what would be > the answer when deploying on K8s? > > Cheers, > Till > > On Wed, Jun 2, 2021 at 12:07 PM Gabor Somogyi <gabor.g.somo...@gmail.com> > wrote: > >> Hi team, >> >> Happy to be here and hope I can provide quality additions in the future. >> >> Thank you all for helpful the suggestions! >> Considering them the FLIP has been modified and the work continues on the >> already existing Jira. >> >> BR, >> G >> >> >> On Wed, Jun 2, 2021 at 11:23 AM Márton Balassi <balassi.mar...@gmail.com> >> wrote: >> >>> Thanks, Chesney - I totally missed that. Answered on the ticket too, let >>> us continue there then. >>> >>> Till, I agree that we should keep this codepath as slim as possible. It >>> is an important design decision that we aim to keep the list of >>> authentication protocols to a minimum. We believe that this should not be a >>> primary concern of Flink and a trusted proxy service (for example Apache >>> Knox) should be used to enable a multitude of enduser authentication >>> mechanisms. The bare minimum of authentication mechanisms to support >>> consequently consist of a single strong authentication protocol for which >>> Kerberos is the enterprise solution and HTTP Basic primary for development >>> and light-weight scenarios. >>> >>> Added the above wording to G's doc. >>> >>> https://docs.google.com/document/d/1NMPeJ9H0G49TGy3AzTVVJVKmYC0okwOtqLTSPnGqzHw/edit >>> >>> >>> >>> On Tue, Jun 1, 2021 at 11:47 AM Chesnay Schepler <ches...@apache.org> >>> wrote: >>> >>>> There's a related effort: >>>> https://issues.apache.org/jira/browse/FLINK-21108 >>>> >>>> On 6/1/2021 10:14 AM, Till Rohrmann wrote: >>>> > Hi Gabor, welcome to the Flink community! >>>> > >>>> > Thanks for sharing this proposal with the community Márton. In >>>> general, I >>>> > agree that authentication is missing and that this is required for >>>> using >>>> > Flink within an enterprise. The thing I am wondering is whether this >>>> > feature strictly needs to be implemented inside of Flink or whether a >>>> proxy >>>> > setup could do the job? Have you considered this option? If yes, then >>>> it >>>> > would be good to list it under the point of rejected alternatives. >>>> > >>>> > I do see the benefit of implementing this feature inside of Flink if >>>> many >>>> > users need it. If not, then it might be easier for the project to not >>>> > increase the surface area since it makes the overall maintenance >>>> harder. >>>> > >>>> > Cheers, >>>> > Till >>>> > >>>> > On Mon, May 31, 2021 at 4:57 PM Márton Balassi <mbala...@apache.org> >>>> wrote: >>>> > >>>> >> Hi team, >>>> >> >>>> >> Firstly I would like to introduce Gabor or G [1] for short to the >>>> >> community, he is a Spark committer who has recently transitioned to >>>> the >>>> >> Flink Engineering team at Cloudera and is looking forward to >>>> contributing >>>> >> to Apache Flink. Previously G primarily focused on Spark Streaming >>>> and >>>> >> security. >>>> >> >>>> >> Based on requests from our customers G has implemented Kerberos and >>>> HTTP >>>> >> Basic Authentication for the Flink Dashboard and HistoryServer. >>>> Previously >>>> >> lacked an authentication story. >>>> >> >>>> >> We are looking to contribute this functionality back to the >>>> community, we >>>> >> believe that given Flink's maturity there should be a common code >>>> solution >>>> >> for this general pattern. >>>> >> >>>> >> We are looking forward to your feedback on G's design. [2] >>>> >> >>>> >> [1] http://gaborsomogyi.com/ >>>> >> [2] >>>> >> >>>> >> >>>> https://docs.google.com/document/d/1NMPeJ9H0G49TGy3AzTVVJVKmYC0okwOtqLTSPnGqzHw/edit >>>> >> >>>> >>>>
