You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Swapnil Bawaskar <sb...@pivotal.io> on 2017/04/25 21:48:28 UTC
Finer grained security
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?
Re: Finer grained security
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
Thanks for feedback! I have tried to incorporate this on our wiki:
https://cwiki.apache.org/confluence/display/GEODE/Finer+grained+security.
Comments welcome.
On Thu, Apr 27, 2017 at 1:33 PM John Blum <jb...@pivotal.io> wrote:
> +1 to Jake's comments, and is a fundamental property of Java's security
> internally.
>
> On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
>
> > Typical solution to the X service needs to create something it service Y
> > where user has permission to X but not to Y is to treat the actions on Y
> > performed by X to be trusted. Often I have seen this implemented such
> that
> > after asserting permission on "create" on X that X performs actions on Y
> as
> > a trusted principal, like a "SYSTEM" user. The other option is to give
> each
> > service a trusted account and elevate to "SERVICE-X" where Y would allow
> > "SERVICE-X" to perform some set of operations.
> >
> > See
> > https://docs.oracle.com/javase/7/docs/api/javax/
> > security/auth/Subject.html#doAs(javax.security.auth.
> > Subject,%20java.security.PrivilegedAction
> > )
> >
> > -Jake
> >
> >
> > On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz <ms...@pivotal.io>
> wrote:
> >
> > > We have seen users who need per-Region permission for Data read/write,
> so
> > > there is precedent there at least.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> > >
> > > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <
> > pulkit.chandra@gmail.com>
> > > wrote:
> > >
> > > > 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 <ds...@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 <
> > > > dhardman@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 <ji...@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 <
> > > jbarrett@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 <
> > > jstewart@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 <
> > > > > > sbawaskar@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>
Re: Finer grained security
Posted by John Blum <jb...@pivotal.io>.
+1 to Jake's comments, and is a fundamental property of Java's security
internally.
On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> Typical solution to the X service needs to create something it service Y
> where user has permission to X but not to Y is to treat the actions on Y
> performed by X to be trusted. Often I have seen this implemented such that
> after asserting permission on "create" on X that X performs actions on Y as
> a trusted principal, like a "SYSTEM" user. The other option is to give each
> service a trusted account and elevate to "SERVICE-X" where Y would allow
> "SERVICE-X" to perform some set of operations.
>
> See
> https://docs.oracle.com/javase/7/docs/api/javax/
> security/auth/Subject.html#doAs(javax.security.auth.
> Subject,%20java.security.PrivilegedAction
> )
>
> -Jake
>
>
> On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz <ms...@pivotal.io> wrote:
>
> > We have seen users who need per-Region permission for Data read/write, so
> > there is precedent there at least.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <
> pulkit.chandra@gmail.com>
> > wrote:
> >
> > > 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 <ds...@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 <
> > > dhardman@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 <ji...@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 <
> > jbarrett@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 <
> > jstewart@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 <
> > > > > sbawaskar@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
-John
john.blum10101 (skype)
Re: Finer grained security
Posted by Jacob Barrett <jb...@pivotal.io>.
Typical solution to the X service needs to create something it service Y
where user has permission to X but not to Y is to treat the actions on Y
performed by X to be trusted. Often I have seen this implemented such that
after asserting permission on "create" on X that X performs actions on Y as
a trusted principal, like a "SYSTEM" user. The other option is to give each
service a trusted account and elevate to "SERVICE-X" where Y would allow
"SERVICE-X" to perform some set of operations.
See
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/Subject.html#doAs(javax.security.auth.Subject,%20java.security.PrivilegedAction
)
-Jake
On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz <ms...@pivotal.io> wrote:
> We have seen users who need per-Region permission for Data read/write, so
> there is precedent there at least.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <pu...@gmail.com>
> wrote:
>
> > 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 <ds...@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 <
> > dhardman@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 <ji...@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 <
> jbarrett@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 <
> jstewart@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 <
> > > > sbawaskar@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
> > > > >
> > > >
> > >
> >
>
Re: Finer grained security
Posted by Michael Stolz <ms...@pivotal.io>.
We have seen users who need per-Region permission for Data read/write, so
there is precedent there at least.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <pu...@gmail.com>
wrote:
> 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 <ds...@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 <
> dhardman@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 <ji...@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 <jb...@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 <jstewart@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 <
> > > sbawaskar@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
> > > >
> > >
> >
>
Re: Finer grained security
Posted by pulkit chandra <pu...@gmail.com>.
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 <ds...@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 <dh...@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 <ji...@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 <jb...@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 <js...@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 <
> > sbawaskar@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
> > >
> >
>
Re: Finer grained security
Posted by Dan Smith <ds...@pivotal.io>.
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 <dh...@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 <ji...@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 <jb...@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 <js...@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 <
> sbawaskar@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
> >
>
Re: Finer grained security
Posted by Diane Rose Hardman <dh...@pivotal.io>.
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 <ji...@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 <jb...@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 <js...@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 <sb...@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
>
Re: Finer grained security
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <jb...@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 <js...@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 <sb...@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
Re: Finer grained security
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <js...@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 <sb...@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?
>
>
Re: Finer grained security
Posted by Jared Stewart <js...@pivotal.io>.
+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 <sb...@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?