If I'm understanding how this security zone concept would work, I think making decisions about the placement of components on the canvas according to authorization would introduce a lot of confusion around understanding the data flow itself and how it is supposed to work.
To me a big part of access policy management that NiFi lacks is the ability to think about it from an individual user/user group perspective. That would help those user(s) tasked with managing policies easily think about and control "what Matt can see and do" and "what the HR group can see and do." Perhaps a more engaging UI with drag and drop capabilities would be useful to help manage it. There I could see the concept of security zones or profiles (roles?) to help. I'm all for exploring those options, but I think that experience should happen outside the canvas and not influence decisions made when building a data flow. Rob On Thu, Jan 19, 2017 at 9:33 AM, Matt Gilman <matt.c.gil...@gmail.com> wrote: > Thanks for starting this DISCUSS. This is definitely an area that we need > to continue improving. > > The concept of a security zone seems like it could be implemented using a > Process Group. However, if I'm following along the difference being that > the security zone does not visually hide encapsulated components. Koji's > comment about allowing components to share a security zone but not be > co-located is interesting as well. Continuing down this thought process, > defining security zones using a selector-like mechanism would allow the > security zones to automatically update (kind of like a smart playlist). > > Definitely some good ideas here. As we continue to introduce these sorts of > efficiencies we'll need to ensure we have a rock solid UX to ensure there > is no ambiguity regarding the component policies at any point in time. > > Matt > > On Wed, Jan 18, 2017 at 8:50 PM, Koji Kawamura <ijokaruma...@gmail.com> > wrote: > > > Hi Andy, > > > > I like this idea, too! Enabling security policy for multiple components > is > > definitely useful. > > > > While I was thinking about the security zone concept, I was wondering if > > components those share the same level of security policy stay close in 2 > > Dimensional position on a flow. Maybe those components would scatter > around > > in a flow, and it'd be hard to put them in a single rectangle area. > > > > One alternative approach to apply policy to components came up. > > That is managing components by adding TAGs or Classes as such in CSS > class. > > Then like CSS, specify policies to a particular class. We will also able > > to alter visual style on NiFi flow based on the style. > > > > Just an idea, but wanted to share. > > > > Thanks, > > Koji > > > > > > On Thu, Jan 19, 2017 at 9:49 AM, Andy LoPresto <alopre...@apache.org> > > wrote: > > > >> Thanks for the feedback so far. I don’t want to cut off conversation > >> here, I just wanted to see if this was worth exploring further and it > seems > >> it is. I would love to hear additional input from (among others) Andre > Fucs > >> de Miranda and Anders Braindahl who have both offered really valuable > >> security insight in the past, Matt Gilman who is the Oracle of NiFi > policy, > >> and Rob Moran who would know how to make this actually look appealing > and > >> work the way users expect. > >> > >> I’ll open a ticket for this to facilitate further conversation and make > >> it trackable. > >> > >> Andy LoPresto > >> alopre...@apache.org > >> *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> > >> On Jan 18, 2017, at 3:50 PM, Jeremy Farbota <jfarb...@payoff.com> > wrote: > >> > >> I like this idea. I like moving some of the security controls into the > >> UI. Using this with Process Groups would be an adequate level of > >> granularity for me. I think this would add a lot of value to the UI and > >> adding security policy controls to UI enables super users to manage the > >> security without needing root access on the server. This could simplify > the > >> process of recreating NiFi environments because you can see the security > >> policies in the UI instead of needing to look at the configs. > >> > >> On Wed, Jan 18, 2017 at 12:38 PM, Andy LoPresto <alopre...@apache.org> > >> wrote: > >> > >>> I just opened NIFI-3370 [1] for “apply access control polices > >>> simultaneously to multiple selected components” and related it to a > >>> previous large ticket NIFI-3115 [2] “enhance user policy management > >>> functionality” with a grab bag of thoughts I had on that. I had another > >>> idea for this but it’s a little out of left field so I wanted to get > some > >>> community feedback before I opened a ticket and see if people thought > it > >>> was a good idea or too confusing/unnecessary. > >>> > >>> Imagine the concept of “security zones” on the canvas. I diagrammed > >>> these with labels currently, but we could obviously modify the > appearance > >>> sufficiently (forgive the screenshot; I was in the middle of reviewing > a PR > >>> that doesn’t include restricted processors, nor was it secured). The > zone > >>> gets one or more policies defined (in my example “Not accessible by > Matt” > >>> or “Accessible only by HR group”) and then components can be dragged > >>> into/out of the zone by an authorized user. Once a component is in the > zone > >>> (and snapping would be enabled to remove ambiguity about what is in or > out > >>> if it overlaps), it inherits the policies defined by that zone. The > >>> policies could be marked by origin (inherited from zone, applied > manually, > >>> etc.) and there is an audit log, so if the component is dragged out of > the > >>> zone, any policies only inherited from that zone could be removed and > it > >>> would “re-inherit” just the root policies. For only one or two > components, > >>> it doesn’t save much time, but you could drag snippets, flow sections, > and > >>> process groups in and out of the zone. > >>> > >>> I think this would make visual assignment and recognition of (sometimes > >>> complex) policies much easier, and greatly reduce the amount of > dialogs and > >>> searches that occur. > >>> > >>> Very interested in feedback from the group at large. Could just be a > >>> wild goose chase and there are better solutions out there. > >>> > >>> [1] https://issues.apache.org/jira/browse/NIFI-3370 > >>> [2] https://issues.apache.org/jira/browse/NIFI-3115 > >>> > >>> > >>> Andy LoPresto > >>> alopre...@apache.org > >>> *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > >>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >>> > >>> > >> > >> > >> -- > >> *Jeremy Farbota* > >> Software Engineer, Data > >> Payoff, Inc. > >> > >> jfarb...@payoff.com > >> (217) 898-8110 <+2178988110> > >> > >> > >> > > >
