I'm just coming up to speed on Knox so maybe rewriting assets links are trivial. If anyone has a good example of how to do that or can point to some documentation, please share.
On Mon, Nov 12, 2018 at 8:54 AM Simon Elliston Ball < si...@simonellistonball.com> wrote: > Doing the Knox proxy work first certainly does make a lot of sense vs the > SSO first approach, so I'm in favour of this. It bypasses all the anti-CORS > proxying stuff the other solution needed by being on the same URL space. > > Is there are reason we're not re-writing the asset link URLs in Knox? We > should have a reverse content rewrite rule to avoid that problem and make > it entirely transparent whether there is Knox or not. We shouldn't be > changing anything about the UI services themselves. If the rewrite service > is complete, there is no change to base ref in the UI code, Knox would > effectively apply it by content filtering. Note also that the gateway URL > is configurable and likely to vary from Knox to Knox, so baking it into the > ng build will break non-full-dev builds. (e.g. gateway/default could well > be gateway/xyz). > > I would also like to discuss removing the JDBC auth, because it's a set of > plaintext passwords in a mysql DB... it introduces a problematic dependency > (mysql) a ton of java dependencies we could cut out (JPA, eclipselink) and > opens up a massive security hole. I personally know of several > organisations who are blocked from using Metron by the presence of the JDBC > authentication method in its current form. > > Simon > > On Mon, 12 Nov 2018 at 14:36, Ryan Merriman <merrim...@gmail.com> wrote: > > > Let me clarify on exposing both legacy and Knox URLs at the same time. > The > > base urls will look something like this: > > > > Legacy REST - http://node1:8082/api/v1 > > Legacy Alerts UI - http://node1:4201:/alerts-list > > > > Knox REST - https://node1:8443/gateway/default/metron/api/v1 > > Knox Alerts UI - > > https://node1:8443/gateway/default/metron-alerts-ui/alerts-list > > > > If Knox were turned on and the alerts UI deployed as is, it would not > > work. This is because static assets are referenced with > > http://node1:4201/assets/some-asset.js which does not include the > correct > > context path to the alerts UI in knox. To make it work, you have to set > > the base ref to "/gateway/default/metron-alerts-ui" so that static assets > > are referenced at > > https://node1:8443/gateway/default/metron-alerts-ui/assets/some-asset.js > . > > When you do that, the legacy alerts UI will no longer work. I guess the > > point I'm trying to make is that we would have to switch between them or > > have 2 separate application running. I imagine most users only need one > or > > the other running so probably not an issue. > > > > Jon, the primary upgrade consideration I see is with authentication. To > be > > able to use Knox, you would have to upgrade to LDAP-based authentication > if > > you were still using JDBC-based authentication in REST. The urls would > > also change obviously. > > > > On Sun, Nov 11, 2018 at 6:38 PM zeo...@gmail.com <zeo...@gmail.com> > wrote: > > > > > Phew, that was quite the thread to catch up on. > > > > > > I agree that this should be optional/pluggable to start, and I'm > > interested > > > to hear the issues as they relate to upgrading an existing cluster > (given > > > the suggested approach) and exposing both legacy and knox URLs at the > > same > > > time. > > > > > > Jon > > > > > > On Fri, Nov 9, 2018, 4:46 PM Michael Miklavcic < > > > michael.miklav...@gmail.com> > > > wrote: > > > > > > > A couple more things, and I think this goes without saying - whatever > > we > > > do > > > > with Knox should NOT > > > > > > > > 1. Require unit and integration tests to use Knox > > > > 2. Break fulldev > > > > > > > > Also, I don't know that I saw you mention this, but I'm unsure how we > > > > should leverage Knox as a core piece of the platform. i.e. should we > > make > > > > this required or optional? I'm open to hearing opinions on this, but > > I'm > > > > inclined to keep this a pluggable option. > > > > > > > > Mike > > > > > > > > > > > > On Fri, Nov 9, 2018 at 2:42 PM Michael Miklavcic < > > > > michael.miklav...@gmail.com> wrote: > > > > > > > > > Thanks for the update Ryan. Per my earlier comments, I thought it > > might > > > > be > > > > > the case that we could dramatically simplify this by leveraging > > Knox's > > > > > proxy capabilities, and per your research that appears to be the > > case. > > > > This > > > > > is a dramatic simplification and improvement of this feature imo, > +1. > > > I'm > > > > > also +1 on a couple distinct steps that you've laid out: fix the UI > > > > issues > > > > > in master, then add Knox for SSO. That should help mitigate issues > > with > > > > > merge conflicts with ongoing development. > > > > > > > > > > > I think it will be a challenge exposing the UIs through both the > > Knox > > > > > url and legacy urls at the same time. > > > > > I'm not sure I understand the issue here. Are you referring to this > > > > > comment? "Added a ng build option to build the UI with base href > set > > to > > > > > Knox base path." Isn't it just a matter of URL > rewriting/forwarding? > > I > > > > > thought we'd be exposing the URL's directly in one context, and > > through > > > > > Knox in the other. Either way, it seems like we should be able to > > > > provide a > > > > > dynamic base path through configuration in our web applications. > I'd > > > > expect > > > > > to modify that property based on whether Knox is configured or not. > > > > > > > > > > > I'm also not clear on how one would use Knox with REST set to > > legacy > > > > > JDBC-based authentication. As far as I know Knox does not support > > JDBC > > > so > > > > > there would be a mismatch between Knox and REST. > > > > > I'm OK with not having Knox work with JDBC. That's a feature of > Knox > > > and > > > > > probably not something we care much about. > > > > > > > > > > >We could initially make Knox an optional feature that requires > setup > > > > with > > > > > the help of some documentation (like Kerberos) while keeping the > > system > > > > the > > > > > way it is now by default. > > > > > Sounds good to me. > > > > > > > > > > > I imagine we'll deprecate JDBC-based authentication at some point > > so > > > > > that may be a good time to switch. > > > > > I would like to announce deprecation in our next release and move > to > > > > > remove it in a following release. > > > > > > > > > > Thanks for taking this on and great job laying things out. > > > > > > > > > > Thanks, > > > > > Mike > > > > > > > > > > On Fri, Nov 9, 2018 at 2:09 PM Ryan Merriman <merrim...@gmail.com> > > > > wrote: > > > > > > > > > >> I have spent some time recently reviewing this discussion and the > > > > feature > > > > >> branch that Simon put out. I think this is an important feature > and > > > > want > > > > >> to move it forward. I started another discussion on adding Knox > to > > > our > > > > >> stack but this discussion has a lot of good context so I will > > continue > > > > it > > > > >> here. > > > > >> > > > > >> I think the main point of contention was that this feature branch > > > > included > > > > >> several different architectural changes and it was unclear if they > > > were > > > > >> needed and if so, could be done separately. Fortunately LDAP > > > > >> authentication has been accepted into master so we can cross it > off > > > the > > > > >> list. From my understanding of the points people have made, that > > > leaves > > > > >> Knox related SSO changes and migrating expressjs to a different, > > > > JVM-based > > > > >> web server that includes proxying capabilities (Zuul). > > > > >> > > > > >> I think everyone agrees that if we can limit the scope to just > Knox > > > > >> related > > > > >> SSO changes that would be ideal. I believe I have found a way to > do > > > > that > > > > >> while working on a small POC this week. The key to this (Simon > > > alluded > > > > to > > > > >> it earlier) is to put both REST and our UIs behind Knox. I > > initially > > > > was > > > > >> focused on just adding REST as a service in Knox and decided to > > > > experiment > > > > >> with also adding our UIs. After I did this it became clear that > > this > > > > >> simplifies things considerably: > > > > >> > > > > >> - The REST app and the UIs are now served from the same host so > > > CORS > > > > >> concerns go away. > > > > >> - We no longer need to worry about proxying REST requests from > > the > > > > UIs > > > > >> with express or Zuul because Knox handles that for us. This > will > > > > make > > > > >> our > > > > >> express configuration even simpler. In fact, all we need is a > > > simple > > > > >> way > > > > >> to serve static UI assets. > > > > >> - We no longer need to check for SSO tokens and redirect in the > > UI > > > > >> web/app servers (or the REST app for that matter) because Knox > > > > handles > > > > >> that > > > > >> for us. > > > > >> - The UIs can now easily access any Knox service (not just our > > REST > > > > >> app) > > > > >> without any extra proxy configuration. > > > > >> - SSO token authentication is only necessary in REST so there > is > > no > > > > >> need > > > > >> to create shared Spring modules or split functionality out. > > > > >> > > > > >> The most significant change I had to make (borrowed from Simon's > > > feature > > > > >> branch) was the SSO token authentication mentioned above. The > > primary > > > > >> short term benefit with this approach is that outside of some > > general > > > > >> deficiencies unrelated to this our UI architecture doesn't need to > > > > >> fundamentally change. I could summarize the changes as: > > > > >> > > > > >> - Knox install and configuration (setting up REST and the > alerts > > UI > > > > as > > > > >> Knox services) > > > > >> - Added Knox SSO token authentication to REST > > > > >> - Updated REST urls in the UI code (should be configurable) > > > > >> - Fixed a few UI bugs where relative paths were not being used > > > > >> - Added a ng build option to build the UI with base href set to > > > Knox > > > > >> base path ( > > > > >> > > > > >> > > > > > > > > > > https://github.com/angular/angular-cli/wiki/build#base-tag-handling-in-indexhtml > > > > >> ) > > > > >> > > > > >> Most the UI changes are preexisting, minor issues that could be > > fixed > > > > >> directly in master. We would need to think of an approach for the > > > base > > > > >> href build requirement but I'm sure it's not that bad. > > > > >> > > > > >> However there will be some backwards compatibility issues we would > > > need > > > > to > > > > >> think through. I think it will be a challenge exposing the UIs > > > through > > > > >> both the Knox url and legacy urls at the same time. I'm also not > > > clear > > > > on > > > > >> how one would use Knox with REST set to legacy JDBC-based > > > > authentication. > > > > >> As far as I know Knox does not support JDBC so there would be a > > > mismatch > > > > >> between Knox and REST. Knox does have the ability to pass along > > basic > > > > >> authentication headers so LDAP in REST would work. We could > > initially > > > > >> make > > > > >> Knox an optional feature that requires setup with the help of some > > > > >> documentation (like Kerberos) while keeping the system the way it > is > > > now > > > > >> by > > > > >> default. I imagine we'll deprecate JDBC-based authentication at > > some > > > > >> point > > > > >> so that may be a good time to switch. > > > > >> > > > > >> What do people think about this approach? Concerns? Are there > any > > > huge > > > > >> holes in this I'm not thinking about? > > > > >> > > > > >> I want to highlight that the work Simon did in his feature branch > > was > > > > >> crucial to better understanding this. I am pretty sure we'll end > up > > > > >> reusing a lot code from that branch. > > > > >> > > > > >> On Thu, Sep 27, 2018 at 6:30 PM Michael Miklavcic < > > > > >> michael.miklav...@gmail.com> wrote: > > > > >> > > > > >> > Apparently, I hit send on my last email before finishing my > > synopsis > > > > >> (per > > > > >> > @Otto's Q in Slack). To summarize, based on my current > > > understanding I > > > > >> > believe that each of the feature branch changes I've outline > above > > > are > > > > >> > units of work that are related, yet should be executed on > > > > independently. > > > > >> > Knox SSO in its own feature branch. Migrating technologies like > > > NodeJs > > > > >> or > > > > >> > migrating the auth DB to LDAP seem like they belong in their own > > > > >> separate > > > > >> > PR's or feature branches. > > > > >> > > > > > >> > Thanks, > > > > >> > Mike > > > > >> > > > > > >> > On Thu, Sep 27, 2018 at 4:08 PM Casey Stella < > ceste...@gmail.com> > > > > >> wrote: > > > > >> > > > > > >> > > I'm coming in late to the game here, but for my mind a feature > > > > branch > > > > >> > > should involve the minimum architectural change to accomplish > a > > > > given > > > > >> > > feature. > > > > >> > > The feature in question is SSO integration. It seems to me > that > > > the > > > > >> > > operative question is can we do the feature without making the > > > OTHER > > > > >> > > architectural change > > > > >> > > (e.g. migrating from expressjs to spring boot + zuul). I > would > > > > argue > > > > >> > that > > > > >> > > if we WANT to do that, then it should be a separate feature > > > branch. > > > > >> > > > > > > >> > > Thus, I leave with a question: is there a way to accomplish > this > > > > >> feature > > > > >> > > without ripping out expressjs? > > > > >> > > > > > > >> > > - If so and it is feasible, I would argue that we should > > > decouple > > > > >> this > > > > >> > > into a separate feature branch. > > > > >> > > - If so and it is infeasible, I'd like to hear an argument > as > > > to > > > > >> the > > > > >> > > infeasibility and let's decide given that > > > > >> > > - If it is not possible, then I'd argue that we should keep > > > them > > > > >> > coupled > > > > >> > > and move this through as-is. > > > > >> > > > > > > >> > > On a side-note, it feels a bit weird that we're narrowing to a > > > > bundled > > > > >> > > proxy, rather than having that be a pluggable thing. I'm not > > > super > > > > >> > > knowledgeable in this space, so I apologize > > > > >> > > in advance if this is naive, but isn't this a pluggable, > > external > > > > >> > component > > > > >> > > (e.g. nginx)? > > > > >> > > > > > > >> > > On Thu, Sep 27, 2018 at 5:05 PM Michael Miklavcic < > > > > >> > > michael.miklav...@gmail.com> wrote: > > > > >> > > > > > > >> > > > I've spent some more time reading through Simon's response > and > > > the > > > > >> > added > > > > >> > > > sequence diagram. This is definitely helpful - thank you > > Simon. > > > > >> > > > > > > > >> > > > I need to redact my initial list: > > > > >> > > > > > > > >> > > > 1. Node migrated to Spring Boot, expressjs migrated to a > > > > >> > > > non-JS/non-NodeJs proxying mechanism (ie Zuul in this > case) > > > > >> > > > 2. JDBC removed completely in favor of LDAP > > > > >> > > > 3. Knox/SSO > > > > >> > > > > > > > >> > > > I'm a bit conflicted on the best way to move forward and > would > > > > like > > > > >> > some > > > > >> > > > thoughts from other community members on this. I think an > > > argument > > > > >> can > > > > >> > be > > > > >> > > > made that 1 and 2 are independent of 3, and should/could > > really > > > be > > > > >> > > > independent PR's against master. > > > > >> > > > > > > > >> > > > The need for a replacement for expressjs (Zuul in this case) > > is > > > an > > > > >> > > artifact > > > > >> > > > that our request/response cycle for REST calls is a simple > > > matter > > > > of > > > > >> > > > forwarding with some additional headers for authentication. > > > > There's > > > > >> a > > > > >> > > > JSESSIONID managed by the client browser in our current > > > > >> architecture, > > > > >> > for > > > > >> > > > example. You login to the alerts or the management UI which > > > > >> forwards a > > > > >> > > > request to REST, which looks up credentials in a backend > > > database, > > > > >> and > > > > >> > > > passes the results back up the chain. All browser requests > go > > > > >> directly > > > > >> > to > > > > >> > > > the specific UI you're working with - this is the CORS > > problem. > > > > You > > > > >> > > can't, > > > > >> > > > without some effort with headers for adding other domains to > > the > > > > >> safe > > > > >> > > list > > > > >> > > > or disabling the security check for CORS, make remote calls > > > > >> directly to > > > > >> > > > REST. That's why we proxy. Switching over to Spring Boot > > leaves > > > a > > > > >> gap > > > > >> > > with > > > > >> > > > expressjs having handled the proxying and filtering, since > > it's > > > > only > > > > >> > > > available to a NodeJs application (it's server-side > javascript > > > vs > > > > >> the > > > > >> > > > client side javascript deployed via our Angular > applications). > > > > Enter > > > > >> > > Zuul, > > > > >> > > > which now effectively handles that. At runtime, Zuul is a > part > > > of > > > > >> the > > > > >> > > > Spring app that serves up our UI's. It handles the requests > > via > > > > >> > > filtering, > > > > >> > > > forwards them to REST, manages the response back to the > > client. > > > > Very > > > > >> > > > similar to what expressjs was doing, per my current > > > understanding. > > > > >> The > > > > >> > > > sequence diagrams Simon added are useful, and I think some > of > > > what > > > > >> was > > > > >> > > less > > > > >> > > > clear was what we currently vs what the new changes are > doing > > to > > > > the > > > > >> > > > architecture. This is no fault of Simon's - there simply > > wasn't > > > > any > > > > >> > > > architecture diagrams/documents around this before. Here's > my > > > > >> > impression > > > > >> > > of > > > > >> > > > the very very basic current state - someone more familiar > with > > > > this > > > > >> > > > architecture please advise if I'm incorrect about anything > > > > (probably > > > > >> > > Ryan). > > > > >> > > > > > > > >> > > > https://imgur.com/f8GtSmh > > > > >> > > > > > > > >> > > > Zuul would be replacing the bit about expressjs in the > > diagram, > > > > and > > > > >> > > instead > > > > >> > > > of node we have spring boot. This covers 1. 2 and 3 are > other > > > > >> issues. > > > > >> > I'd > > > > >> > > > like to see similar exposition of those server processes > with > > > knox > > > > >> > > > involved. I imagine in that case we bump up from 3 to 4 > server > > > > >> > instances > > > > >> > > > for the additional knox endpoint. > > > > >> > > > > > > > >> > > > Mike > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > On Wed, Sep 19, 2018 at 11:28 AM James Sirota < > > > jsir...@apache.org > > > > > > > > > >> > > wrote: > > > > >> > > > > > > > >> > > > > Thank you, Simon. The diagrams help a lot > > > > >> > > > > > > > > >> > > > > 19.09.2018, 21:27, "Simon Elliston Ball" < > > > > >> > si...@simonellistonball.com > > > > >> > > >: > > > > >> > > > > > To clarify some of this I've put some documentation into > > > > >> > > > > > https://github.com/apache/metron/pull/1203 under > > > METRON-1755 > > > > ( > > > > >> > > > > > https://issues.apache.org/jira/browse/METRON-1755). > > > Hopefully > > > > >> the > > > > >> > > > > diagrams > > > > >> > > > > > there should make it clearer. > > > > >> > > > > > > > > > >> > > > > > Simon > > > > >> > > > > > > > > > >> > > > > > On Tue, 18 Sep 2018 at 14:17, Simon Elliston Ball < > > > > >> > > > > > si...@simonellistonball.com> wrote: > > > > >> > > > > > > > > > >> > > > > >> Hi Mike, > > > > >> > > > > >> > > > > >> > > > > >> Some good points here which could do with some > > > > clarification. > > > > >> I > > > > >> > > > suspect > > > > >> > > > > >> the architecture documentation could be clearer and > fill > > > in > > > > >> some > > > > >> > of > > > > >> > > > > these > > > > >> > > > > >> gaps, and I'll have a look at working on that and > > > providing > > > > >> some > > > > >> > > > > diagrams. > > > > >> > > > > >> > > > > >> > > > > >> The short version is that the Zuul proxy gateway has > > been > > > > >> added > > > > >> > to > > > > >> > > > > replace > > > > >> > > > > >> the Nodejs express proxy used to gateway the REST api > > > calls > > > > in > > > > >> > the > > > > >> > > > > current > > > > >> > > > > >> hosts. This is done in both cases to avoid CORS > > > restrictions > > > > >> by > > > > >> > > > > allowing > > > > >> > > > > >> the same host that serves the UI files to proxy call > to > > > the > > > > >> API. > > > > >> > > > > >> > > > > >> > > > > >> The choice of Zuul was partly a pragmatic one (it's > the > > > one > > > > >> > that's > > > > >> > > > > there > > > > >> > > > > >> in the box as it were with Spring Boot, which we use > for > > > the > > > > >> REST > > > > >> > > > API, > > > > >> > > > > via > > > > >> > > > > >> the Spring Cloud Netflix project which wraps a bunch > of > > > > >> related > > > > >> > > > pieces > > > > >> > > > > into > > > > >> > > > > >> Spring). The choice of Spring Boot to host the UIs > > > > themselves > > > > >> was > > > > >> > > > > similarly > > > > >> > > > > >> for parity with the REST host, to simplify the stack > (we > > > > >> remove > > > > >> > the > > > > >> > > > > >> occasionally problematic need to install nodejs on > > target > > > > >> > servers, > > > > >> > > > > which is > > > > >> > > > > >> outside of the regular OS and HDP stacks we support). > > > > >> > > > > >> > > > > >> > > > > >> Arguably, the Zuul proxy is not necessary if we force > > > > >> everything > > > > >> > > > > through a > > > > >> > > > > >> Knox instance, since Knox would provide a single > > endpoint. > > > > We > > > > >> > > > probably > > > > >> > > > > >> however don't want to force Knox and SSL, hence using > > Zuul > > > > to > > > > >> > keep > > > > >> > > it > > > > >> > > > > >> closer to our current architecture. Zuul does some > other > > > > nice > > > > >> > > things, > > > > >> > > > > which > > > > >> > > > > >> might help us in future, so it's really about laying > > down > > > > some > > > > >> > > > options > > > > >> > > > > for > > > > >> > > > > >> potentially doing micro-services style things at a > later > > > > date. > > > > >> > I'm > > > > >> > > > not > > > > >> > > > > >> saying we have to, or even should go that way, it will > > > just > > > > >> make > > > > >> > > life > > > > >> > > > > >> easier later if we decide to. It will also help us if > we > > > > want > > > > >> to > > > > >> > > add > > > > >> > > > > HA, > > > > >> > > > > >> circuit breaking etc to the architecture at a later > > date. > > > > That > > > > >> > > said, > > > > >> > > > I > > > > >> > > > > >> regret that I ever said the word micro-services, since > > > it's > > > > >> > caused > > > > >> > > > > >> confusion. Just think of it as a proxy to deal with > the > > > CORS > > > > >> > > problem. > > > > >> > > > > >> > > > > >> > > > > >> Zuul is implemented as a set of filters, but we are > not > > > > using > > > > >> it > > > > >> > > for > > > > >> > > > > its > > > > >> > > > > >> authentication filtering. We're using it as a proxy. > > Shiro > > > > is > > > > >> an > > > > >> > > > > >> authentication framework, and could arguably used to > > > provide > > > > >> the > > > > >> > > > > security > > > > >> > > > > >> piece, but frankly wrapping shiro as a replacement for > > > > Spring > > > > >> > > > Security > > > > >> > > > > in a > > > > >> > > > > >> Spring application seemed like it will make life a lot > > > > harder. > > > > >> > This > > > > >> > > > > could > > > > >> > > > > >> be done, but it's not the native happy path, and would > > > pull > > > > in > > > > >> > > > > additional > > > > >> > > > > >> dependencies that duplicate functionality that's > already > > > > >> embedded > > > > >> > > in > > > > >> > > > > Spring > > > > >> > > > > >> Security. > > > > >> > > > > >> > > > > >> > > > > >> The version of Knox used is the default from HDP. The > > link > > > > >> > version > > > > >> > > > you > > > > >> > > > > >> mention is a docs link. I'll update it to be the older > > > > >> version, > > > > >> > > which > > > > >> > > > > is > > > > >> > > > > >> the same and we can decide if we want to maintain the > > > > >> freshness > > > > >> > of > > > > >> > > it > > > > >> > > > > when > > > > >> > > > > >> we look to upgrade underlying patterns. Either way, > the > > > > >> content > > > > >> > is > > > > >> > > > the > > > > >> > > > > >> same. > > > > >> > > > > >> > > > > >> > > > > >> I did consider other hosting mechanisms, including > > > Undertow > > > > a > > > > >> > > > > >> > > > > >> > > > > >> If you have a different suggestion to using the Spring > > > > default > > > > >> > ways > > > > >> > > > of > > > > >> > > > > >> doing things, or we want to use a framework other than > > > > Spring > > > > >> for > > > > >> > > > this, > > > > >> > > > > >> then maybe we could change to that, but the route > chosen > > > > here > > > > >> is > > > > >> > > > > definitely > > > > >> > > > > >> the easy path in the context of the decision made to > use > > > > >> Spring > > > > >> > in > > > > >> > > > > metron > > > > >> > > > > >> rest, and if anything opens up our choices while > > > minimising, > > > > >> in > > > > >> > > fact > > > > >> > > > > >> reducing, our dependency management overhead. > > > > >> > > > > >> > > > > >> > > > > >> I hope that explains some of the thinking behind the > > > choices > > > > >> > made, > > > > >> > > > but > > > > >> > > > > the > > > > >> > > > > >> guiding principals I followed were: > > > > >> > > > > >> * Don't fight the framework if you don't have to > > > > >> > > > > >> * Reduce the need for additional installation pieces > and > > > > third > > > > >> > > party > > > > >> > > > > repos > > > > >> > > > > >> * Minimize dependencies we would have to manage > > > > >> > > > > >> * Avoid excessive change of the architecture, or > forcing > > > > >> users to > > > > >> > > > adopt > > > > >> > > > > >> Knox if they didn't want the SSL overhead. > > > > >> > > > > >> > > > > >> > > > > >> Simon > > > > >> > > > > >> > > > > >> > > > > >> On Tue, 18 Sep 2018 at 02:46, Michael Miklavcic < > > > > >> > > > > >> michael.miklav...@gmail.com> wrote: > > > > >> > > > > >> > > > > >> > > > > >>> Thanks for the write-up Ryan, this is a great start. > I > > > have > > > > >> some > > > > >> > > > > further > > > > >> > > > > >>> questions based on your feedback and in addition to > my > > > > >> initial > > > > >> > > > thread. > > > > >> > > > > >>> > > > > >> > > > > >>> Just for clarification, what version of Knox are we > > > using? > > > > >> HDP > > > > >> > > > 2.6.5, > > > > >> > > > > >>> which > > > > >> > > > > >>> is what we currently run full dev against, supports > > > 0.12.0. > > > > >> > > > > >>> > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_release-notes/content/comp_versions.html > > > > >> > > > > >>> . > > > > >> > > > > >>> I see references to Knox 1.1.0 (latest) in this > > committed > > > > PR > > > > >> - > > > > >> > > > > >>> > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://github.com/apache/metron/pull/1111/files#diff-70b412194819f3cb829566f05d77c1a6R122 > > > > >> > > > > >>> . > > > > >> > > > > >>> This is probably just a super small mismatch, and it > > > > probably > > > > >> > goes > > > > >> > > > > without > > > > >> > > > > >>> saying, but I just want to be doubly sure that we're > > > > >> installing > > > > >> > > the > > > > >> > > > > >>> default > > > > >> > > > > >>> via the standard install mechanism as opposed to > > > something > > > > >> > > separate > > > > >> > > > > and > > > > >> > > > > >>> manual. > > > > >> > > > > >>> > > > > >> > > > > >>> On the subject of Zuul wrt Nodejs filters. I'd like > to > > > hear > > > > >> some > > > > >> > > > more > > > > >> > > > > >>> detail on: > > > > >> > > > > >>> > > > > >> > > > > >>> 1. Why do we need filtering via Zuul? For > instance, > > is > > > > >> > > filtering > > > > >> > > > > >>> routing > > > > >> > > > > >>> not handled by Knox? From the beginner docs: "The > > > > gateway > > > > >> > > itself > > > > >> > > > > is a > > > > >> > > > > >>> layer > > > > >> > > > > >>> over an embedded Jetty JEE server. At the very > > highest > > > > >> level > > > > >> > > the > > > > >> > > > > >>> gateway > > > > >> > > > > >>> processes requests by using request URLs to lookup > > > > >> specific > > > > >> > JEE > > > > >> > > > > Servlet > > > > >> > > > > >>> Filter chain that is used to process the request. > > The > > > > >> gateway > > > > >> > > > > framework > > > > >> > > > > >>> provides extensible mechanisms to assemble chains > of > > > > >> custom > > > > >> > > > filters > > > > >> > > > > >>> that > > > > >> > > > > >>> support secured access to services." [1] > > > > >> > > > > >>> 2. What other library options were considered for > > this > > > > >> > feature > > > > >> > > > and > > > > >> > > > > how > > > > >> > > > > >>> was it chosen over the others? I search on "apache > > > > spring > > > > >> web > > > > >> > > > > filters" > > > > >> > > > > >>> and > > > > >> > > > > >>> it's almost all about Shiro - > > > > >> > > > https://shiro.apache.org/spring.html. > > > > >> > > > > I > > > > >> > > > > >>> also see quite a bit about filtering for Spring > Boot > > > > >> > > applications > > > > >> > > > > along > > > > >> > > > > >>> with a write-up of how to accomplish the same with > > Web > > > > MVC > > > > >> > > here - > > > > >> > > > > >>> > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://stackoverflow.com/questions/19825946/how-to-add-a-filter-class-in-spring-boot > > > > >> > > > > >>> . > > > > >> > > > > >>> The Knox documentation boilerplate examples are > also > > > > using > > > > >> > > Shiro. > > > > >> > > > > >>> "shiro.ini - The configuration file for the Shiro > > > > >> > > authentication > > > > >> > > > > >>> provider’s > > > > >> > > > > >>> filters. This information is derived from the > > > > information > > > > >> in > > > > >> > > the > > > > >> > > > > >>> provider > > > > >> > > > > >>> section of the topology file." [1] > > > > >> > > > > >>> > > > > >> > > > > >>> My assumption is that there are deliberate decisions > in > > > > >> favor of > > > > >> > > > this > > > > >> > > > > mix > > > > >> > > > > >>> of technologies over others, and I think some > > additional > > > > >> > > explanation > > > > >> > > > > will > > > > >> > > > > >>> make that clear. As it stands per the Knox > > documentation, > > > > it > > > > >> > looks > > > > >> > > > > like > > > > >> > > > > >>> we're going on a different route from the > > > > >> preferred/recommended > > > > >> > > > > idioms. > > > > >> > > > > >>> > > > > >> > > > > >>> [1] > > > > >> > > > > >>> > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > http://knox.apache.org/books/knox-0-12-0/dev-guide.html#Architecture+Overview > > > > >> > > > > >>> > > > > >> > > > > >>> Ryan, I agree about microservices. This should not > > derail > > > > nor > > > > >> > be a > > > > >> > > > > major > > > > >> > > > > >>> part of discussion around this feature, imho. I think > > > > there's > > > > >> > > quite > > > > >> > > > a > > > > >> > > > > bit > > > > >> > > > > >>> left to discuss on that subject. I want to make sure > > that > > > > >> we're > > > > >> > > not > > > > >> > > > > >>> prematurely favoring architectural choices by pulling > > in > > > > >> > libraries > > > > >> > > > > that > > > > >> > > > > >>> are > > > > >> > > > > >>> potentially opinionated about how to accomplish those > > > > goals. > > > > >> If > > > > >> > > they > > > > >> > > > > are, > > > > >> > > > > >>> I > > > > >> > > > > >>> would expect we are comfortable ripping those > libraries > > > out > > > > >> if > > > > >> > the > > > > >> > > > > >>> community favors a different direction. > > > > >> > > > > >>> > > > > >> > > > > >>> On the subject of Spring Boot vs Nodejs. I can see > some > > > > >> > rationale > > > > >> > > > for > > > > >> > > > > >>> making things homogenous (though, in a microservices > > > > >> > architecture, > > > > >> > > > if > > > > >> > > > > we > > > > >> > > > > >>> go > > > > >> > > > > >>> that route, that's not strictly necessary), but what > is > > > the > > > > >> > > > > justification > > > > >> > > > > >>> for Spring Boot over Nodejs? Why would want one over > > the > > > > >> other? > > > > >> > > > > >>> > > > > >> > > > > >>> On Mon, Sep 17, 2018 at 3:38 PM Ryan Merriman < > > > > >> > > merrim...@gmail.com> > > > > >> > > > > >>> wrote: > > > > >> > > > > >>> > > > > >> > > > > >>> > I have reviewed a couple different PRs so I'll add > > some > > > > >> > context > > > > >> > > > > where I > > > > >> > > > > >>> > can. Obviously Simon would be the most qualified to > > > > answer > > > > >> but > > > > >> > > > I'll > > > > >> > > > > >>> add my > > > > >> > > > > >>> > thoughts. > > > > >> > > > > >>> > > > > > >> > > > > >>> > For question 1, while they may not all be > necessary I > > > > >> think it > > > > >> > > > does > > > > >> > > > > make > > > > >> > > > > >>> > sense to include them in this feature branch if our > > > > primary > > > > >> > goal > > > > >> > > > is > > > > >> > > > > >>> > integrating Knox SSO. We could push off removing > JDBC > > > > >> > > > authentication > > > > >> > > > > >>> for > > > > >> > > > > >>> > reasons I'll get to in my response to question 2. > If > > we > > > > >> want > > > > >> > to > > > > >> > > do > > > > >> > > > > one > > > > >> > > > > >>> at > > > > >> > > > > >>> > a time (switch to spring boot, add Zuul as a > > > dependency, > > > > >> then > > > > >> > > add > > > > >> > > > > Knox > > > > >> > > > > >>> SSO) > > > > >> > > > > >>> > then that's ok but I do think there are > dependencies > > > and > > > > >> > should > > > > >> > > be > > > > >> > > > > done > > > > >> > > > > >>> in > > > > >> > > > > >>> > order. For example, adding Knox SSO requires some > > work > > > > >> around > > > > >> > > > > request > > > > >> > > > > >>> > filtering. If we were to do this before moving to > > > Spring > > > > >> Boot > > > > >> > we > > > > >> > > > > would > > > > >> > > > > >>> > need to implement the filters in Nodejs which would > > be > > > > >> > throwaway > > > > >> > > > > once we > > > > >> > > > > >>> > get around to migrating away from that. For Zuul, I > > > > believe > > > > >> > it's > > > > >> > > > > >>> purpose > > > > >> > > > > >>> > is to facilitate the filtering (although it does a > > lot > > > > >> more) > > > > >> > so > > > > >> > > it > > > > >> > > > > >>> doesn't > > > > >> > > > > >>> > make sense to add that separate from the Knox SSO > > work. > > > > >> > > > > >>> > > > > > >> > > > > >>> > For question 2, I think you bring up a good point. > We > > > > >> probably > > > > >> > > > don't > > > > >> > > > > >>> want > > > > >> > > > > >>> > to just rip our current authentication method out. > We > > > > might > > > > >> > want > > > > >> > > > to > > > > >> > > > > >>> > consider deprecating it instead and making Knox SSO > > and > > > > >> LDAP > > > > >> > > > > >>> authentication > > > > >> > > > > >>> > optional. > > > > >> > > > > >>> > > > > > >> > > > > >>> > For question 3, this is a bigger shift than just a > > > > >> component > > > > >> > > > > upgrade. > > > > >> > > > > >>> It's > > > > >> > > > > >>> > more like shifting platforms, from Elasticsearch to > > > Solr > > > > >> for > > > > >> > > > > example. > > > > >> > > > > >>> Like > > > > >> > > > > >>> > I alluded to in my response to question 1, I don't > > > think > > > > we > > > > >> > > should > > > > >> > > > > >>> require > > > > >> > > > > >>> > throwaway work just because we want to review these > > > parts > > > > >> > > > > separately. > > > > >> > > > > >>> > > > > > >> > > > > >>> > For question 4, I will defer to Simon. I don't > > believe > > > we > > > > >> > > > > necessarily > > > > >> > > > > >>> > require Zuul so I will let him elaborate on why he > > > choose > > > > >> that > > > > >> > > > > library > > > > >> > > > > >>> and > > > > >> > > > > >>> > what the potential impact is of adding it to our > > > project. > > > > >> > > > > >>> > > > > > >> > > > > >>> > For question 5 and 6, I will also defer to Simon on > > > this. > > > > >> The > > > > >> > > > focus > > > > >> > > > > of > > > > >> > > > > >>> > this feature as I understand it is a consistent > > > > >> authentication > > > > >> > > > > mechanism > > > > >> > > > > >>> > and support for SSO. I will let him lay out his > > vision > > > > for > > > > >> > micro > > > > >> > > > > >>> services. > > > > >> > > > > >>> > > > > > >> > > > > >>> > Knox SSO would be a great improvement and is what I > > > think > > > > >> we > > > > >> > > > should > > > > >> > > > > >>> focus > > > > >> > > > > >>> > on in this feature branch. Micro services is > > something > > > we > > > > >> > should > > > > >> > > > > >>> certainly > > > > >> > > > > >>> > discuss but it might be a bit of a distraction and > I > > > > >> wouldn't > > > > >> > > want > > > > >> > > > > to > > > > >> > > > > >>> hold > > > > >> > > > > >>> > up the other useful parts. > > > > >> > > > > >>> > > > > > >> > > > > >>> > On Fri, Sep 14, 2018 at 8:38 PM Michael Miklavcic < > > > > >> > > > > >>> > michael.miklav...@gmail.com> wrote: > > > > >> > > > > >>> > > > > > >> > > > > >>> > > Hey all, > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > I started looking through the Knox SSO feature > > branch > > > > >> (see > > > > >> > > here > > > > >> > > > > >>> > > > https://issues.apache.org/jira/browse/METRON-1663 > > ). > > > > >> This is > > > > >> > > > some > > > > >> > > > > >>> great > > > > >> > > > > >>> > new > > > > >> > > > > >>> > > security functionality work and it looks like it > > will > > > > >> bring > > > > >> > > some > > > > >> > > > > >>> > important > > > > >> > > > > >>> > > new features to the Metron platform. I'm coming > at > > > this > > > > >> > pretty > > > > >> > > > > green, > > > > >> > > > > >>> so > > > > >> > > > > >>> > I > > > > >> > > > > >>> > > do have some questions regarding the proposed > > changes > > > > >> from a > > > > >> > > > high > > > > >> > > > > >>> level > > > > >> > > > > >>> > > architectural perspective. There are a few > changes > > > > within > > > > >> > the > > > > >> > > > > current > > > > >> > > > > >>> FB > > > > >> > > > > >>> > > PR's that I think could use some further > > explanation. > > > > At > > > > >> > first > > > > >> > > > > >>> glance, it > > > > >> > > > > >>> > > seems we could potentially simplify this branch a > > > great > > > > >> deal > > > > >> > > and > > > > >> > > > > get > > > > >> > > > > >>> it > > > > >> > > > > >>> > > completed much sooner if we narrowed the focus a > > bit. > > > > >> But I > > > > >> > > > could > > > > >> > > > > >>> > certainly > > > > >> > > > > >>> > > be wrong here and happy for other opinions. I > > > searched > > > > >> > through > > > > >> > > > the > > > > >> > > > > >>> > mailing > > > > >> > > > > >>> > > list history to see if there is any additional > > > > background > > > > >> > and > > > > >> > > > the > > > > >> > > > > main > > > > >> > > > > >>> > > DISCUSS thread I could find was regarding > initially > > > > >> setting > > > > >> > up > > > > >> > > > the > > > > >> > > > > >>> > feature > > > > >> > > > > >>> > > branch, which talked about adding Knox and LDAP. > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread.html/cac2e6314284015b487121e77abf730abbb7ebec4ace014b19093b4c@%3Cdev.metron.apache.org%3E > > > > >> > > > > >>> > > . > > > > >> > > > > >>> > > If I've missed any follow-up, please let me know. > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > Looking at the broader set of Jiras associated > with > > > > 1663 > > > > >> and > > > > >> > > the > > > > >> > > > > >>> first PR > > > > >> > > > > >>> > > 1665, it looks like there are 4 main thrusts of > > this > > > > >> branch > > > > >> > > > right > > > > >> > > > > now: > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > 1. Knox/SSO > > > > >> > > > > >>> > > 2. Node migrated to Spring Boot > > > > >> > > > > >>> > > 3. JDBC removed completely in favor of LDAP > > > > >> > > > > >>> > > 4. Introduction of Zuul, also microservices? > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > I strongly urge for the purpose of reviewing this > > > > feature > > > > >> > > branch > > > > >> > > > > that > > > > >> > > > > >>> we > > > > >> > > > > >>> > > base much of the discussion off of > > > > >> > > > > >>> > > > https://issues.apache.org/jira/browse/METRON-1755, > > > the > > > > >> > > > > architecture > > > > >> > > > > >>> > > diagram. Minimally, an explanation of the current > > > > >> > architecture > > > > >> > > > > along > > > > >> > > > > >>> with > > > > >> > > > > >>> > > discussion around the additional proposed changes > > and > > > > >> > > rationale > > > > >> > > > > would > > > > >> > > > > >>> be > > > > >> > > > > >>> > > useful for evaluation. I don't have a solid > enough > > > > >> > > understanding > > > > >> > > > > yet > > > > >> > > > > >>> of > > > > >> > > > > >>> > the > > > > >> > > > > >>> > > full scope of changes and how they differ from > the > > > > >> existing > > > > >> > > > > >>> architecture > > > > >> > > > > >>> > > just from looking at the PR's alone. > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > 1. The first question is a general one regarding > > the > > > > >> > necessity > > > > >> > > > of > > > > >> > > > > >>> the > > > > >> > > > > >>> > 3 > > > > >> > > > > >>> > > additional features alongside Knox - migrating > Node > > > to > > > > >> > Spring > > > > >> > > > > Boot, > > > > >> > > > > >>> > > removing JDBC altogether, adding dependencies on > > > > >> Netflix's > > > > >> > > Zuul > > > > >> > > > > >>> > > framework. > > > > >> > > > > >>> > > Are these necessary for adding Knox/SSO? They > seem > > > like > > > > >> > > > > potentially > > > > >> > > > > >>> > > separate features, imo. > > > > >> > > > > >>> > > 2. It looks like LDAP will be a required > component > > > for > > > > >> > > > interacting > > > > >> > > > > >>> > with > > > > >> > > > > >>> > > Metron via the UI's. I see this PR > > > > >> > > > > >>> > > https://github.com/apache/metron/pull/1186 which > > > > removes > > > > >> > JDBC > > > > >> > > > > >>> > > authentication. Are we ready to remove it > > completely > > > or > > > > >> > would > > > > >> > > it > > > > >> > > > > be > > > > >> > > > > >>> > > better > > > > >> > > > > >>> > > to leave it as a minimal installation option? > What > > is > > > > the > > > > >> > > > proposed > > > > >> > > > > >>> > > migration path for existing users? Do we feel > > > > comfortable > > > > >> > > > > requiring > > > > >> > > > > >>> > that > > > > >> > > > > >>> > > all installations, including full dev, install > and > > > > >> configure > > > > >> > > > LDAP? > > > > >> > > > > >>> For > > > > >> > > > > >>> > > comparison, in the PCAP feature branch we > discussed > > > > >> removing > > > > >> > > the > > > > >> > > > > >>> > > existing > > > > >> > > > > >>> > > PCAP REST application in the initial discussion, > > got > > > > >> > > agreement, > > > > >> > > > > and > > > > >> > > > > >>> > > later > > > > >> > > > > >>> > > removed it in the course of working on the > feature > > > > >> branch. > > > > >> > The > > > > >> > > > PR > > > > >> > > > > >>> is > > > > >> > > > > >>> > > fairly > > > > >> > > > > >>> > > clear, however I think we're just missing some > > basic > > > > >> > > discussion > > > > >> > > > > >>> around > > > > >> > > > > >>> > > the > > > > >> > > > > >>> > > implications, as I've outlined above. Some > > additional > > > > >> > relevant > > > > >> > > > > >>> > > discussion > > > > >> > > > > >>> > > occurred on this PR > > > > >> > > https://github.com/apache/metron/pull/1112 > > > > >> > > > > >>> which > > > > >> > > > > >>> > > would be good to summarize for purposes of this > > > > >> overarching > > > > >> > > > > >>> > architecture > > > > >> > > > > >>> > > discussion. > > > > >> > > > > >>> > > 3. Migration from Node to Spring Boot. I believe > > this > > > > is > > > > >> > > already > > > > >> > > > > >>> used > > > > >> > > > > >>> > by > > > > >> > > > > >>> > > the REST application and if anything brings some > > > > >> cohesion to > > > > >> > > our > > > > >> > > > > >>> > server > > > > >> > > > > >>> > > strategy. Strictly speaking, is there a reason > this > > > is > > > > >> > > required > > > > >> > > > > for > > > > >> > > > > >>> > > Knox? > > > > >> > > > > >>> > > It seems comparable to a component upgrade, such > as > > > > >> moving > > > > >> > > from > > > > >> > > > ES > > > > >> > > > > >>> 2.x > > > > >> > > > > >>> > > to > > > > >> > > > > >>> > > 5.6.x and upgrading Angular 6. > > > > >> > > > > >>> > > 4. Introduction of Netflix's Zuul. > > > > >> > > > > >>> > > > https://issues.apache.org/jira/browse/METRON-1665. > > > > >> > > > > >>> > > - > "The UIs currently proxy to the REST API to > > avoid > > > > >> CORS > > > > >> > > > > >>> issues, > > > > >> > > > > >>> > > this will be achieved with Zuul." > > > > >> > > > > >>> > > - Can we elaborate more on where or how CORS is a > > > > problem > > > > >> > with > > > > >> > > > > >>> our > > > > >> > > > > >>> > > existing architecture, how Zuul will help solve > > that, > > > > and > > > > >> > how > > > > >> > > it > > > > >> > > > > >>> > > fits with > > > > >> > > > > >>> > > Knox? Wouldn't this be handled by Knox? Since > Larry > > > > McCay > > > > >> > > > > >>> chimed in > > > > >> > > > > >>> > > with > > > > >> > > > > >>> > > interest on the original SSO thread about the FB, > > I'm > > > > >> hoping > > > > >> > > he > > > > >> > > > > >>> is > > > > >> > > > > >>> > > also > > > > >> > > > > >>> > > willing to chime in on this as well. > > > > >> > > > > >>> > > - This looks like it has the potential to be a > > rather > > > > >> large > > > > >> > > > > >>> piece > > > > >> > > > > >>> > of > > > > >> > > > > >>> > > fundamental infrastructure (as it's also > pertinent > > to > > > > >> > > > > >>> > microservices) > > > > >> > > > > >>> > > to > > > > >> > > > > >>> > > pull into the platform, and I'd like to be sure > the > > > > >> > community > > > > >> > > is > > > > >> > > > > >>> > > aware of > > > > >> > > > > >>> > > and is OK with the implications. > > > > >> > > > > >>> > > 5. > "The proposal is to use a spring boot > > > application, > > > > >> > > allowing > > > > >> > > > > >>> us to > > > > >> > > > > >>> > > harmonize the security implementation across the > UI > > > > >> static > > > > >> > > > servers > > > > >> > > > > >>> and > > > > >> > > > > >>> > > the > > > > >> > > > > >>> > > REST layer, and to provide a routing platform for > > > later > > > > >> > > > > >>> > microservices." > > > > >> > > > > >>> > > - > > > > >> > > > > >>> > > > https://issues.apache.org/jira/browse/METRON-1665. > > > > >> > > > > >>> > > - Microservices is a pretty loaded term. I know > > there > > > > had > > > > >> > been > > > > >> > > > > >>> some > > > > >> > > > > >>> > > discussion a while back during the PCAP feature > > > branch > > > > >> > start, > > > > >> > > > > >>> but I > > > > >> > > > > >>> > > don't > > > > >> > > > > >>> > > recall ever reaching a consensus on it. More > detail > > > in > > > > >> this > > > > >> > > > > >>> thread > > > > >> > > > > >>> > - > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread.html/1db7c6fa1b0f364f8c03520db9989b4f7a446de82eb4d9786055048c@%3Cdev.metron.apache.org%3E > > > > >> > > > > >>> > > . > > > > >> > > > > >>> > > Can we get some clarification on what is meant by > > > > >> > > microservices > > > > >> > > > > >>> > > in the case > > > > >> > > > > >>> > > of this FB and relevant PR's, what that > > architecture > > > > >> looks > > > > >> > > like, > > > > >> > > > > >>> > and > > > > >> > > > > >>> > > how > > > > >> > > > > >>> > > it's achieved with the proposed changes in this > > > PR/FB? > > > > It > > > > >> > > seems > > > > >> > > > > >>> > Zuul > > > > >> > > > > >>> > > is > > > > >> > > > > >>> > > also pertinent to this discussion, but there are > > many > > > > >> ways > > > > >> > to > > > > >> > > > > >>> > > skin this cat > > > > >> > > > > >>> > > so I don't want to presume - > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > https://blog.heroku.com/using_netflix_zuul_to_proxy_your_microservices > > > > >> > > > > >>> > > 6. Zuul, Spring Boot, and microservices - Closely > > > > >> related to > > > > >> > > > > >>> > point 5 > > > > >> > > > > >>> > > above. It seems that we weren't quite ready for > > this > > > > >> when it > > > > >> > > was > > > > >> > > > > >>> > > brought up > > > > >> > > > > >>> > > in May, or at the very least we had some concern > of > > > > what > > > > >> > > > direction > > > > >> > > > > >>> to > > > > >> > > > > >>> > > go. > > > > >> > > > > >>> > > What is the operational impact, mpack impact, and > > how > > > > we > > > > >> > > propose > > > > >> > > > > to > > > > >> > > > > >>> > > manage > > > > >> > > > > >>> > > it with Kerberos, etc.? > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > >> > > > > >>> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread.html/c19904681e6a6d9ea3131be3d1a65b24447dca31b4aff588b263fd87@%3Cdev.metron.apache.org%3E > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > There is a lot to like in this feature branch, > imo. > > > > Great > > > > >> > > > feature > > > > >> > > > > >>> > addition > > > > >> > > > > >>> > > with Knox and SSO. Introduction of LDAP support > for > > > > >> > > > > authentication for > > > > >> > > > > >>> > > Metron UI's. Simplification/unification of our > > server > > > > >> > hosting > > > > >> > > > > >>> > > infrastructure. I'm hoping we can flesh out some > of > > > the > > > > >> > > details > > > > >> > > > > >>> pointed > > > > >> > > > > >>> > out > > > > >> > > > > >>> > > above a bit more and get this feature through. > > Great > > > > >> work so > > > > >> > > > far! > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > Best, > > > > >> > > > > >>> > > Mike Miklavcic > > > > >> > > > > >>> > > > > > > >> > > > > >>> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> > > > > >> -- > > > > >> > > > > >> simon elliston ball > > > > >> > > > > >> @sireb > > > > >> > > > > > > > > > >> > > > > > -- > > > > >> > > > > > -- > > > > >> > > > > > simon elliston ball > > > > >> > > > > > @sireb > > > > >> > > > > > > > > >> > > > > ------------------- > > > > >> > > > > Thank you, > > > > >> > > > > > > > > >> > > > > James Sirota > > > > >> > > > > PMC- Apache Metron > > > > >> > > > > jsirota AT apache DOT org > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > -- > > > > > > Jon Zeolla > > > > > > > > -- > -- > simon elliston ball > @sireb >
