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 <[email protected]> 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 > [email protected] > *[email protected] <[email protected]>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Jan 18, 2017, at 3:50 PM, Jeremy Farbota <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> *[email protected] <[email protected]>* >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> > > > -- > *Jeremy Farbota* > Software Engineer, Data > Payoff, Inc. > > [email protected] > (217) 898-8110 <+2178988110> > > >
