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

Reply via email to