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 <[email protected]> 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 <[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> >> >> >> >
