Telescopic then that there might be flow one has no access to see as
well as other flow one can see but not change? Then do we have flow to
which one can add, but not subtract, etc.? Can one detach from a
protected flow? Can one stop/start protected flows? If a protected flow
cannot be stopped, then one cannot insert before or add to it after. Etc.
It gets creepy ugly, but I suppose if it can be represented and
manipulated visually... What a challenge!
Russ
On 01/19/2017 09:20 AM, Rob Moran wrote:
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 <[email protected]>
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 <[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>
