Hi everyone, Thanks a lot for all the great discussions. To summarize in brief, here are the few approaches we discussed so far:
1. One permission per DAG. The user has homogenous rights on the dag. The concerns: - not flexible to certain use cases(e.g the user has view only access on certain dags and write access on certain other dags ); - difficult to implement as it breaks the existing FAB security model. 2. Extend current model(ab_permission_view_role) with an additional optional column (dag_id). The concerns: - introduce a 3rd column to existing permission_view table. - It requires us to handle db migration carefully from view only access UI to dag level access UI. 3. Define a set of pre-defined dag-level permissions. Reuse the current existing permission_view model and consider each individual dag as a new view. It seems that the 3rd approach is a preferable approach which makes the security model easy to extend without introducing additional complexity. If no other concern, I will work with Max to create an initial proposal / PR based on 3rd approach for the work(https://issues.apache. org/jira/browse/AIRFLOW-2267). Thanks, -Tao On Sat, Mar 31, 2018 at 12:09 AM, Joy Gao <j...@wepay.com> wrote: > +1! > > I was originally tempted to re-use existing perms and views for dag-level > access control since dag-level perm/view is a subset of view-level > perm/view, but your proposal of defining new dag-level perms/views > independent from view-level perms/views is interesting. This actually makes > a lot of sense, since even in the existing models, views can also be menu > options, so we are simply extending the concept of views to include dags as > well. > > On Fri, Mar 30, 2018 at 5:24 PM Maxime Beauchemin < > maximebeauche...@gmail.com> wrote: > > > I'd suggest something else that avoids having to add a 3rd column. I > think > > we can fit our use case into the existing structure nicely. > > > > My idea is to mimic what FAB does with its own Models. > > > > When you create a Model and ModelView in FAB (say DagRun for example), it > > creates a new view_menu (DagRun) and matches it with existing permission > > (can_read, can_delete, can_edit, can_show, ...) to create a new set of > > "permission_views" which are combinations of permission and view_menu as > in > > "DagRun - can_read", "DagRun - can_edit", ... It's not a cartesian > product > > of all perms and view_menus, it's a predetermined list of model-specific > > perms that get combined with DagRun here. > > > > Similarly, when Airflow would detect a new DAG (example "my_dag"), it > > would create a new view_menu `my_dag`, and match it with permissions that > > are identified as "combinable" with DAG. To avoid potential conflicts I'd > > create new permissions that are DAG-specific like "dag_clear", "dag_run", > > "dag_view". > > > > I'm arguing about the how to use the FAB model here specifically. I think > > this allows for all the flexibility we need without changing the model. I > > care less about what exactly the atomicity of the per DAG perms should > look > > like. As far as I'm concerned, per-DAG read and write is probably > granular > > enough > > > > Also note that: > > * we need an "_all_dags" logical DAG, meaning we'd have extra > > permission_views "_all_dags - dag_view", "_all_dags - dag_run", > "all_dags - > > dag_clear" > > * we probably want to derive FAB's SecurityManger and have an > > AirflowSecurityManager that has an extra method "can_dag_action(user, > > dag_id, action)". The SecurityManger class is neat because people can > > provide their own if they want and override methods. That means that you > > can defer any of the security-related checks to another system if you > want > > to. Many companies have some sort of company RBAC system and that can be > > used to integrate with it. > > > > Max > > > > > > > > On Fri, Mar 30, 2018 at 4:54 PM, Joy Gao <j...@wepay.com> wrote: > > > >> Hi all, > >> > >> I also agree that having view-only access to some dags while write > access > >> to other dags is useful, so I prefer option 2. Although option 2 is more > >> difficult to manage, it is cleaner and more consistent with the current > >> security model. (On the other hand, even though option 1 may be may be > >> easier to manage, it might be trickier to implement: with one perm per > >> dag, it breaks the existing FAB security model since the existing, more > >> granular permissions will have to be grouped for each dag). > >> > >> What Brian suggested in the other thread makes sense to me... > >> > >> The current security model in FAB looks like the following: > >> > >> --- permissions > >> user --- role --- permission_view ---| > >> --- views > >> > >> FAB generates a few relationship tables to manage the mappings, one of > >> them is *ab_permission_view_role*, which has all the > >> role-to-permission_view mapping. We can add a dag_id column to this > >> relationship that expresses dag-level granularity, so the security model > >> becomes: > >> > >> --- > >> permissions > >> | > >> user --- role --- dag_permission_view --- --- views > >> | > >> --- > dags > >> > >> We can make the dag_id field an optional field in the relationship, and > >> only lazily add new dag-level mappings for DAGs that specify 'access > >> control'. This way we don't have to create new permissions or views. (We > >> will still have to introduce new dag-level roles on top of the 5 generic > >> roles (public/viewer/user/op/admin)). > >> > >> (I think this is similar to what Arthur suggested earlier, but not sure > >> if I interpreted correctly). > >> > >> Joy > >> > >> On Thu, Mar 29, 2018 at 10:01 AM, Arthur Wiedmer < > >> arthur.wied...@gmail.com> wrote: > >> > >>> (Creating a new thread) > >>> > >>> Hi Max, > >>> > >>> I was just wondering about this. There are definite use cases for > people > >>> having only view access to some DAGs, mostly for monitoring. I want to > know > >>> what the upstream DAGs are doing, but maybe I don't need clear/run > access. > >>> > >>> I feel like the granular operation permissions will start to become > >>> unwieldy fast. It grows as (# users * # DAGs * # operations) but with > >>> hopefully a small constant factor in front: most people should only > have a > >>> small number of DAGs they care about. The Ops team has a need to have > >>> access to all on the other hand. > >>> > >>> I was wondering we could get by with something slightly more complex > but > >>> easier on the size of that permissions table : > >>> 1) One toggle on the user level for broad access (ALL:ALL, > >>> RUN/CLEAR:ALL, VIEW:ALL) default NULL > >>> 2) More granular permissions at the DAG level. > >>> > >>> So in order, check the user's broad level permission first, then DAG > >>> level. For large amounts of DAGs, this should help shave a little bit > from > >>> that table. > >>> > >>> Best, > >>> Arthur > >>> > >>> > >>> On Thu, Mar 29, 2018 at 8:27 AM, Maxime Beauchemin < > >>> maximebeauche...@gmail.com> wrote: > >>> > >>>> Hijacking the thread further here, any thoughts on how to breakdown > per > >>>> DAG > >>>> access? > >>>> > >>>> Tao & I are talking about introducing per-DAG permissions and one big > >>>> question is whether we'll need to support different operation-types > at a > >>>> per-DAG level, which changes the way we need to model the perms. > >>>> > >>>> First [simpler] option is to introduce one perm per DAG. If you have > >>>> access > >>>> to 5 DAGs, and you have `can_clear` and `can_run`, you'll have > >>>> homogenous > >>>> rights on the DAGs you have access to. > >>>> > >>>> Second option is to have a breakdown per DAG. Meaning for each DAG we > >>>> create a set of perms ({dag_id}_can_view, {dag_id}_can_modify, ...). > So > >>>> one > >>>> user could have modify on some DAGs, view on others, and other DAGs > >>>> would > >>>> be invisible. This could be broken down further ({dag_id}_can_clear, > >>>> ...) > >>>> but it gets hard to manage. > >>>> > >>>> Thoughts? > >>>> > >>>> Max > >>>> > >>>> On Wed, Mar 28, 2018 at 10:02 PM, Tao Feng <fengta...@gmail.com> > wrote: > >>>> > >>>> > Great work Joy. This is awesome! I am interested in helping out the > >>>> per dag > >>>> > level access. Just created a ticket to check(AIRFLOW-2267). Let me > >>>> know if > >>>> > you have any suggestions. I will share my proposal once I am ready. > >>>> > > >>>> > On Fri, Mar 23, 2018 at 6:45 PM, Joy Gao <j...@wepay.com> wrote: > >>>> > > >>>> > > Hey guys! > >>>> > > > >>>> > > The RBAC UI <https://github.com/apache/inc > ubator-airflow/pull/3015> > >>>> has > >>>> > > been merged to master. I'm looking forward to early adopters' > >>>> feedback > >>>> > and > >>>> > > bug reports. I also hope to have more folks helping out with the > >>>> RBAC UI, > >>>> > > especially with introducing DAG-Level access control, which is a > >>>> feature > >>>> > > that a lot of people have been asking. If you are interested in > >>>> helping > >>>> > out > >>>> > > with this effort, let's talk more! > >>>> > > > >>>> > > This commit will be in the 1.10.0 release, and we are going to > >>>> maintain > >>>> > > both UIs simultaneously for a short period of time. Once RBAC UI > is > >>>> > stable > >>>> > > and battle-tested, we will deprecate the old UI and eventually > >>>> remove it > >>>> > > from the repo (around Airflow 2.0.0 or 2.1.0 release). This is to > >>>> prevent > >>>> > > two UIs from forking into separate paths, as that would become > very > >>>> > > difficult to maintain. > >>>> > > > >>>> > > Going forward while both UIs are up, if you are making a change to > >>>> any > >>>> > > files in airflow/www/ (old UI), where applicable, please also make > >>>> the > >>>> > > change to the airflow/www_rbac/ (new UI). If you rather not make > >>>> changes > >>>> > in > >>>> > > both UIs, it is recommended that you only make the changes to the > >>>> RBAC > >>>> > UI, > >>>> > > since that is the one we are maintaining in the long term. > >>>> > > > >>>> > > I'm excited that the RBAC UI will be able to bring additional > >>>> security to > >>>> > > Airflow, and with FAB framework in place we can look into > >>>> leveraging it > >>>> > for > >>>> > > a unified set of APIs used by both UI and CLI. > >>>> > > > >>>> > > Joy > >>>> > > > >>>> > > > >>>> > > > >>>> > > On Thu, Feb 8, 2018 at 11:31 AM, Joy Gao <j...@wepay.com> wrote: > >>>> > > > >>>> > > > Hi folks, > >>>> > > > > >>>> > > > I have a PR <https://github.com/apache/ > >>>> incubator-airflow/pull/3015> > >>>> > out > >>>> > > > for the new UI. I've included instructions on how to test it out > >>>> in the > >>>> > > PR > >>>> > > > description. Looking forward to your feedbacks. > >>>> > > > > >>>> > > > Cheers, > >>>> > > > Joy > >>>> > > > > >>>> > > > On Fri, Dec 1, 2017 at 6:18 PM, Joy Gao <j...@wepay.com> wrote: > >>>> > > > > >>>> > > >> Thanks for the background info. Would be really awesome for you > >>>> to > >>>> > have > >>>> > > >> PyPi access :D I'll make the change to have Airflow Webserver's > >>>> FAB > >>>> > > >> dependency pointing to my fork for the mean time. > >>>> > > >> > >>>> > > >> For folks who are interested in RBAC, I will be giving a > >>>> talk/demo at > >>>> > > the Airflow > >>>> > > >> Meet-Up > >>>> > > >> <https://www.meetup.com/Bay-Area-Apache-Airflow-Incubating- > >>>> > > Meetup/events/244525050/> > >>>> > > >> next Monday. Happy to chat afterwards about it as well :) > >>>> > > >> > >>>> > > >> On Thu, Nov 30, 2017 at 8:36 AM, Maxime Beauchemin < > >>>> > > >> maximebeauche...@gmail.com> wrote: > >>>> > > >> > >>>> > > >>> A bit of related history here: > >>>> > > >>> https://github.com/dpgaspar/Flask-AppBuilder/issues/399 > >>>> > > >>> > >>>> > > >>> On Thu, Nov 30, 2017 at 8:33 AM, Maxime Beauchemin < > >>>> > > >>> maximebeauche...@gmail.com> wrote: > >>>> > > >>> > >>>> > > >>> > Given I have merge rights on FAB I could probably do another > >>>> round > >>>> > of > >>>> > > >>> > review and get your PRs through. I would really like to get > >>>> the > >>>> > main > >>>> > > >>> > maintainer's input on things that touch the core > >>>> (composite-key > >>>> > > >>> support) as > >>>> > > >>> > he might have concerns/intuitions that we can't know about. > >>>> > > >>> > > >>>> > > >>> > I do not have Pypi access though so I cannot push new > releases > >>>> > out. I > >>>> > > >>> > could ask for that. > >>>> > > >>> > > >>>> > > >>> > I've threatened to fork the project before, that's always an > >>>> > option. > >>>> > > >>> I've > >>>> > > >>> > noticed his involvement is sporadic and comes in bursts. > >>>> > > >>> > > >>>> > > >>> > In the meantime, you can have the dependency in Airflow > >>>> Webserver > >>>> > > >>> pointing > >>>> > > >>> > straight to your fork. > >>>> > > >>> > > >>>> > > >>> > Max > >>>> > > >>> > > >>>> > > >>> > On Wed, Nov 29, 2017 at 7:02 PM, Joy Gao <j...@wepay.com> > >>>> wrote: > >>>> > > >>> > > >>>> > > >>> >> I just created a new webserver instance if you haven't > >>>> gotten a > >>>> > > >>> chance to > >>>> > > >>> >> fiddle around with the new web UI and the RBAC > configurations > >>>> > > (thanks > >>>> > > >>> >> Maxime for getting started with this earlier!): > >>>> > > >>> >> > >>>> > > >>> >> http://104.209.38.171:8080/ > >>>> > > >>> >> > >>>> > > >>> >> Admin Account > >>>> > > >>> >> username: admin > >>>> > > >>> >> password: admin > >>>> > > >>> >> > >>>> > > >>> >> Read-Only Account > >>>> > > >>> >> username: viewer > >>>> > > >>> >> password: password > >>>> > > >>> >> > >>>> > > >>> >> > >>>> > > >>> >> On Wed, Nov 29, 2017 at 2:58 PM, Joy Gao <j...@wepay.com> > >>>> wrote: > >>>> > > >>> >> > >>>> > > >>> >> > Hi folks, > >>>> > > >>> >> > > >>>> > > >>> >> > Thanks for all the feedback regarding to the new Airflow > >>>> > Webserver > >>>> > > >>> UI > >>>> > > >>> >> > <https://github.com/wepay/airflow-webserver/>! I've been > >>>> > actively > >>>> > > >>> >> > addressing all the bugs that were raised on Github. So I > >>>> want to > >>>> > > >>> take > >>>> > > >>> >> this > >>>> > > >>> >> > opportunity to discuss two issues coming up: > >>>> > > >>> >> > > >>>> > > >>> >> > The first issue is unaddressed PRs in FAB. If these PRs > >>>> continue > >>>> > > to > >>>> > > >>> stay > >>>> > > >>> >> > unaddressed, RBAC is blocked from making further > progress. > >>>> If > >>>> > this > >>>> > > >>> >> continue > >>>> > > >>> >> > to be an issue, I'm inclined to fork FAB, even though > it's > >>>> not > >>>> > > >>> >> idealistic. > >>>> > > >>> >> > > >>>> > > >>> >> > > >>>> > > >>> >> > - PR/631 <https://github.com/dpgaspar/F > >>>> > > lask-AppBuilder/pull/631> > >>>> > > >>> >> Binary > >>>> > > >>> >> > column support (merged, unreleased) > >>>> > > >>> >> > <https://github.com/dpgaspar/F > lask-AppBuilder/pull/631> > >>>> > > >>> >> > - PR/639 <https://github.com/dpgaspar/F > >>>> > > lask-AppBuilder/pull/639> > >>>> > > >>> >> Composite > >>>> > > >>> >> > primary key support (unmerged) > >>>> > > >>> >> > - PR/655 <https://github.com/dpgaspar/F > >>>> > > lask-AppBuilder/pull/655> > >>>> > > >>> >> Form > >>>> > > >>> >> > prefill support (unmerged) > >>>> > > >>> >> > > >>>> > > >>> >> > > >>>> > > >>> >> > The second issue is an open question about the next step > of > >>>> > > Airflow > >>>> > > >>> >> > Webserver itself. Here are the 3 potential directions we > >>>> could > >>>> > > >>> take, and > >>>> > > >>> >> > I've added my thought on each. > >>>> > > >>> >> > > >>>> > > >>> >> > 1. Permanently keep Airflow Webserver as a separated > >>>> package > >>>> > from > >>>> > > >>> >> Airflow, > >>>> > > >>> >> > and treat it as another UI option. Keep `www` in Airflow. > >>>> Allow > >>>> > > >>> >> development > >>>> > > >>> >> > on both UIs. > >>>> > > >>> >> > *I'm not a fan of this. When there is an existing UI in > >>>> Airflow, > >>>> > > >>> most > >>>> > > >>> >> > contributors would prefer to maintain the official > version > >>>> that > >>>> > is > >>>> > > >>> >> > installed out-of-the-box. **Having a second UI outside of > >>>> > Airflow > >>>> > > >>> will > >>>> > > >>> >> > make maintaining it very difficult, leading to an > eventual > >>>> death > >>>> > > of > >>>> > > >>> the > >>>> > > >>> >> new > >>>> > > >>> >> > UI :(* > >>>> > > >>> >> > > >>>> > > >>> >> > 2. Permanently keep Airflow Webserver as a separated > >>>> package > >>>> > from > >>>> > > >>> >> Airflow, > >>>> > > >>> >> > but freeze all development on `www` and direct all > future > >>>> UI > >>>> > > >>> >> development > >>>> > > >>> >> > to Airflow Webserver, eventually removing `www` > completely > >>>> when > >>>> > > >>> Airflow > >>>> > > >>> >> > Webserver is stable. > >>>> > > >>> >> > *I'm not a fan of this either. First of all, the views > and > >>>> > models > >>>> > > >>> are > >>>> > > >>> >> > tightly coupled in both old and new UI; until we have a > >>>> > > full-fledged > >>>> > > >>> >> REST > >>>> > > >>> >> > API to build the UI (and cli) on top of it, separating > >>>> them to a > >>>> > > >>> >> separate > >>>> > > >>> >> > package now will potentially cause dependency issues and > >>>> add > >>>> > > >>> >> complication > >>>> > > >>> >> > to our release cycle. **Secondly, **majority of Airflow > >>>> users > >>>> > run > >>>> > > >>> >> Airflow > >>>> > > >>> >> > with the UI; it's one of Airflow's best features. > >>>> Separating UI > >>>> > > out > >>>> > > >>> of > >>>> > > >>> >> > Airflow core will complicate setup and configuration, > while > >>>> > making > >>>> > > >>> >> Airflow > >>>> > > >>> >> > core less complete.* > >>>> > > >>> >> > > >>>> > > >>> >> > 3. Merge Airflow Webserver back into Airflow as `www2`, > >>>> freeze > >>>> > all > >>>> > > >>> >> > development on `www`, eventually removing `www` > completely > >>>> when > >>>> > > >>> `www2` > >>>> > > >>> >> is > >>>> > > >>> >> > stable. > >>>> > > >>> >> > *This makes the most sense to me. Airflow Webserver is > >>>> developed > >>>> > > >>> with > >>>> > > >>> >> the > >>>> > > >>> >> > goal of feature parity to the current UI, plus additional > >>>> RBAC > >>>> > > >>> >> capability, > >>>> > > >>> >> > in hope to replace the old UI completely. Yes, this means > >>>> there > >>>> > > >>> will be > >>>> > > >>> >> a > >>>> > > >>> >> > short period of having to maintain two UIs, but once we > >>>> freeze > >>>> > > >>> >> development > >>>> > > >>> >> > on www, it shouldn't be a concern for long.* > >>>> > > >>> >> > > >>>> > > >>> >> > I'd love to hear everyone's thoughts on this! I'm excited > >>>> about > >>>> > > >>> bringing > >>>> > > >>> >> > RBAC to airflow and I hope it's something others will > find > >>>> > useful > >>>> > > as > >>>> > > >>> >> well! > >>>> > > >>> >> > > >>>> > > >>> >> > Cheers, > >>>> > > >>> >> > Joy > >>>> > > >>> >> > > >>>> > > >>> >> > On Mon, Nov 20, 2017 at 11:24 AM, Joy Gao < > j...@wepay.com> > >>>> > wrote: > >>>> > > >>> >> > > >>>> > > >>> >> >> Thank you everyone for the active feedback so far, and > >>>> thanks > >>>> > for > >>>> > > >>> >> setting > >>>> > > >>> >> >> up the demo Maxime! > >>>> > > >>> >> >> > >>>> > > >>> >> >> Going to work on pruning through the issues in the > >>>> upcoming > >>>> > days. > >>>> > > >>> >> >> > >>>> > > >>> >> >> Fokko/Maxime, do you recall the SQLAlchemy Exception > >>>> message > >>>> > so I > >>>> > > >>> can > >>>> > > >>> >> >> look into it? Otherwise I'll wait until it's down again > =P > >>>> > > >>> >> >> > >>>> > > >>> >> >> Cheers, > >>>> > > >>> >> >> > >>>> > > >>> >> >> Joy > >>>> > > >>> >> >> > >>>> > > >>> >> >> On Mon, Nov 20, 2017 at 9:35 AM, Maxime Beauchemin < > >>>> > > >>> >> >> maximebeauche...@gmail.com> wrote: > >>>> > > >>> >> >> > >>>> > > >>> >> >>> I just restarted it, not sure how long it will take to > >>>> get in > >>>> > a > >>>> > > >>> bad > >>>> > > >>> >> state > >>>> > > >>> >> >>> again... > >>>> > > >>> >> >>> > >>>> > > >>> >> >>> Max > >>>> > > >>> >> >>> > >>>> > > >>> >> >>> On Sun, Nov 19, 2017 at 11:55 PM, Driesprong, Fokko > >>>> > > >>> >> <fo...@driesprong.frl > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> wrote: > >>>> > > >>> >> >>> > >>>> > > >>> >> >>> > Good morning, > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > The demo provided by Max is down, it throws a > >>>> > > >>> SQLAlchemyexception > >>>> > > >>> >> :'( > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > Cheers, Fokko > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > 2017-11-18 19:14 GMT+01:00 Chris Riccomini < > >>>> > > >>> criccom...@apache.org>: > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > > @bolke, open issues on the Github repo, please. > >>>> > > >>> >> >>> > > > >>>> > > >>> >> >>> > > On Sat, Nov 18, 2017 at 10:13 AM, Bolke de Bruin < > >>>> > > >>> >> bdbr...@gmail.com> > >>>> > > >>> >> >>> > > wrote: > >>>> > > >>> >> >>> > > > >>>> > > >>> >> >>> > > > Chris, > >>>> > > >>> >> >>> > > > > >>>> > > >>> >> >>> > > > Do you want us to report bugs somewhere (I have > >>>> > > encountered > >>>> > > >>> a > >>>> > > >>> >> >>> few)? Or > >>>> > > >>> >> >>> > > > just generic user experiences posted here? > >>>> > > >>> >> >>> > > > > >>>> > > >>> >> >>> > > > Cheers > >>>> > > >>> >> >>> > > > Bolke > >>>> > > >>> >> >>> > > > > >>>> > > >>> >> >>> > > > > On 18 Nov 2017, at 00:47, Chris Riccomini < > >>>> > > >>> >> criccom...@apache.org > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > > wrote: > >>>> > > >>> >> >>> > > > > > >>>> > > >>> >> >>> > > > > Hey all, > >>>> > > >>> >> >>> > > > > > >>>> > > >>> >> >>> > > > > I know the weekend is coming up, and for those > >>>> of us > >>>> > in > >>>> > > >>> the > >>>> > > >>> >> US, > >>>> > > >>> >> >>> next > >>>> > > >>> >> >>> > > week > >>>> > > >>> >> >>> > > > > is a bit of a slow holiday week. Would love to > >>>> get > >>>> > some > >>>> > > >>> >> feedback > >>>> > > >>> >> >>> from > >>>> > > >>> >> >>> > > > > everyone on this. The goal would ideally to be > to > >>>> > > >>> converge on > >>>> > > >>> >> >>> this > >>>> > > >>> >> >>> > and > >>>> > > >>> >> >>> > > > > eventually replace the existing Airflow UI with > >>>> this > >>>> > > one. > >>>> > > >>> >> >>> > > > > > >>>> > > >>> >> >>> > > > > Cheers, > >>>> > > >>> >> >>> > > > > Chris > >>>> > > >>> >> >>> > > > > > >>>> > > >>> >> >>> > > > > On Fri, Nov 17, 2017 at 1:44 PM, Joy Gao < > >>>> > > j...@wepay.com> > >>>> > > >>> >> wrote: > >>>> > > >>> >> >>> > > > > > >>>> > > >>> >> >>> > > > >> Hi guys. > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > >> I've been working on moving airflow from > >>>> Flask-Admin > >>>> > to > >>>> > > >>> >> >>> > > Flask-AppBuilder > >>>> > > >>> >> >>> > > > >> for RBAC > >>>> > > >>> >> >>> > > > >> <https://cwiki.apache.org/ > >>>> > confluence/display/AIRFLOW/ > >>>> > > >>> >> >>> > > > Airflow+RBAC+proposal > >>>> > > >>> >> >>> > > > >>> , > >>>> > > >>> >> >>> > > > >> check it out at > https://github.com/wepay/airfl > >>>> > > >>> ow-webserver. > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > >> It's still a work-in-progress, but most > >>>> features you > >>>> > > see > >>>> > > >>> in > >>>> > > >>> >> the > >>>> > > >>> >> >>> > > > webserver > >>>> > > >>> >> >>> > > > >> UI today is available there. For those who are > >>>> > > >>> interested in > >>>> > > >>> >> >>> RBAC, > >>>> > > >>> >> >>> > I'd > >>>> > > >>> >> >>> > > > love > >>>> > > >>> >> >>> > > > >> to get some early feedback in terms of the > >>>> following: > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > >> - New Flask-AppBuilder UI (any > bugs/regressions) > >>>> > > >>> >> >>> > > > >> - Setup issues > >>>> > > >>> >> >>> > > > >> - Ease of integration with third party auth > >>>> (i.e. > >>>> > LDAP, > >>>> > > >>> AD, > >>>> > > >>> >> >>> OAuth, > >>>> > > >>> >> >>> > > etc.) > >>>> > > >>> >> >>> > > > >> - Any other thoughts/concerns > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > >> Thanks a lot! > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > >> Cheers, > >>>> > > >>> >> >>> > > > >> Joy > >>>> > > >>> >> >>> > > > >> > >>>> > > >>> >> >>> > > > > >>>> > > >>> >> >>> > > > > >>>> > > >>> >> >>> > > > >>>> > > >>> >> >>> > > >>>> > > >>> >> >>> > >>>> > > >>> >> >> > >>>> > > >>> >> >> > >>>> > > >>> >> > > >>>> > > >>> >> > >>>> > > >>> > > >>>> > > >>> > > >>>> > > >>> > >>>> > > >> > >>>> > > >> > >>>> > > > > >>>> > > > >>>> > > >>>> > >>> > >>> > >> > > >