For per instance permission, I would say look for the evidence. Do we have evidence that customers want per instance permission? If not may be implement minimally in the first cut and validate with customers if they want per instance model?
About Lucene concern, It is in fact good to provide permission for per logical operation that implementation is doing. This will align the security permission with operations performed and provide better design of a role. I would argue if you are able to perform 2 logically separate operations with single permission is perhaps a smell that you might not have enough permissions. my $0.02 On Wed, 26 Apr 2017 at 16:54 Dan Smith <dsm...@pivotal.io> wrote: > I agree that async event queues seem like a different case than wan or > disk. In that case you are not using anything that creating a region > doesn't do. > > Shouldn't creating a region be DATA:MANAGE:DISK? Requiring DATA privileges > for a region without disk and CLUSTER privileges for a region with disk > seems weird. Same issues with creating a region that uses WAN. > > -Dan > > On Wed, Apr 26, 2017 at 12:53 PM, Diane Rose Hardman <dhard...@pivotal.io> > wrote: > > > One more possible complication is that creating a Lucene index will also > > create an AsyncEventQueue. Today the required permission to create the > AEQ > > is DATA:MANAGE which coincidentally nicely matches the permission > required > > to create an OQL index. > > Pulling out the AEQ as a separate resource will affect Lucene index > > creation. FYI. > > > > On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > > DATA:*:RegionA would allow you to only operate that region but not all > of > > > them. > > > > > > if we want to control a specific wan, maybe we add a fourth parameter: > > > cluster:*:wan:wanName, same goes for Disk etc. > > > > > > On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett <jbarr...@pivotal.io> > > > wrote: > > > > > > > Think further, what about the team that ask that I be able to mange a > > > > region not all regions, or a wan not all wan. It may be time to think > > > about > > > > a full per instance / > > > > named resource based security model. > > > > > > > > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart <jstew...@pivotal.io> > > > wrote: > > > > > > > > > +1 > > > > > > > > > > I think it would also be a good idea to move the current operations > > > > > permitted by CLUSTER:MANAGE ( stop server, alter runtime, etc) to > > > require > > > > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid > ambiguity. > > > > (This > > > > > is not a breaking change since CLUSTER:MANAGE implies > > > > > CLUSTER:MANAGE:MEMBER.) > > > > > > > > > > > On Apr 25, 2017, at 2:48 PM, Swapnil Bawaskar < > > sbawas...@pivotal.io> > > > > > wrote: > > > > > > > > > > > > In our current security model, a user with DATA:MANAGE can create > > > > > regions, > > > > > > create disk stores, WAN gateways etc. I think this is a very wide > > > > scope, > > > > > > because an administrator may want to give create region privilege > > to > > > a > > > > > > developer, but not necessarily give them the ability to create > disk > > > > > stores > > > > > > or send the data in that region over WAN. I propose that we > refine > > > the > > > > > > security model to make it finer grained. > > > > > > > > > > > > I propose that Disk, WAN and AsyncQueue be treated as resources > in > > > the > > > > > > security framework. These resources will be controlled at the > > CLUSTER > > > > > > level. As with any other resource, admins will be able to grant > > READ, > > > > > WRITE > > > > > > and MANAGE permissions to these resources. In terms of shiro, > this > > > will > > > > > > take the form: CLUSTER:READ/WRITE/MANAGE:DISK,WAN,ASYNCQUEUE. > > > > > > > > > > > > Here is how it will work out for each resource: > > > > > > DISK > > > > > > 1. CLUSTER:MANAGE:DISK - allows users to create/manage disk > stores > > > > > > 2. CLUSTER:WRITE:DISK - allows users to create regions that > > > > > write/overflow > > > > > > to disk stores > > > > > > 3. CLUSTER:READ:DISK - should be covered by DATA:READ, does not > > make > > > > > sense > > > > > > here > > > > > > > > > > > > WAN: > > > > > > 1. CLUSTER:MANAGE:WAN - allows users to create gateway senders > and > > > > > receivers > > > > > > 2. CLUSTER:WRITE:WAN - allows users to create regions that write > > data > > > > to > > > > > > gateway senders > > > > > > 3. CLUSTER:READ:WAN - allows users to create regions that read > data > > > > from > > > > > > gateway receivers > > > > > > > > > > > > We can add other things like functions here as well. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > > >
