I think the reason why its different from the CliFrontend is that the sql client is way younger and as far as I know never reached "production" readiness. (as per the docs [1], it's still marked as Beta, plus see the first "Attention" ;) ).
I think it certainly makes sense to have a proper security story. In a way that's also where my question about which parts of the sql client you would see guarded with kerberos. I think well put requirements in that area, could make a really great feature request. Catalogs are certainly a good point, as the client accesses catalogs to query the schema even before submitting the job. Best, Dawid On 24/03/2020 13:50, Gyula Fóra wrote: > Thanks Dawid, > > I think you are right that most of the things should work like this > just fine. Maybe some catalogs will need this at some point but not > right now, > I was just wondering why is this different from how the CliFrontend > works which also installs the security context on the Client side. > > I guess same arguments should apply for the SQL CLI, whatever they > might be :) > > Gyula > > On Tue, Mar 24, 2020 at 12:30 PM Dawid Wysakowicz > <dwysakow...@apache.org <mailto:dwysakow...@apache.org>> wrote: > > Hi Gyula, > > As far as I can tell SQL cli does not support Kerberos natively. > SQL CLI > submits all the queries to a running Flink cluster. Therefore if you > kerberize the cluster the queries will use that configuration. > > On a different note. Out of curiosity. What would you expect the > SQL CLI > to use the Kerberos authentication for? > > Best, > > Dawid > > On 24/03/2020 11:11, Gyula Fóra wrote: > > Hi! > > > > Does the SQL CLI support Kerberos Authentication? > > > > I am struggling to find any use of the SecurityContext in the > SQL CLI > > logic but maybe I am looking in the wrong place. > > > > Thank you! > > Gyula >
signature.asc
Description: OpenPGP digital signature
