+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?
