[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
--------------------------------
Description:
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: "the keyspace list". These resources should be mapped into
a hierarchy, and an object representing the path to the resource will be passed
to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/<cluster_name>/keyspaces/<ks_name>/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| <cluster_name>/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| <ks_name>/ | READ, WRITE, MODIFY_SCHEMA | An individual keyspace: since this
is the last entry in the current hierarchy, READ/WRITE apply recursively to
ancestor _data_ of the keyspace, while FULL applies recursively to ancestor
_schemas_ of the keyspace. |
(Note that {{/cassandra/}} and {{<cluster_name>/}} will not yet be checked for
permissions via a call to IAuthority.authorize, so while it would be possible
for an IAuthority backend to store permissions for these top level resources,
they will only be able to deny access when a user attempts to access an
ancestor resource.)
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but this
initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces.
was:
Once 1237 is completed, we'd like to improve AccessLevels so that they can be
applied to the global scope, instead of just individual keyspaces.
Steps for this ticket:
* Improve/replace the AccessLevel structure to be more like a set of boolean
permissions, rather than being level based
* Store a global map of (users/groups)->AccessLevel that will define which
users have permission to create/remove/list keyspaces.
** This map would be persisted in the "system" keyspace, or in the Migrations
keyspace in such a fashion that modifying permissions on one node ripples out
to the rest
* Add a client interface method that allows adding/removing permissions in the
global map (set_global_permissions ?)
----
Expected usecase, starting from an empty cluster, with authentication enabled:
# Set a password for a "super/root" user (that has been predefined in Cassandra
by default) in an IAuthenticator specific way
# Super user authenticates in Thrift
# Super user gives more users permission to create/list/remove keyspaces via
the proposed Thrift 'set_global_permissions' method
# Users authenticate via Thrift
# Users create/remove/list keyspaces
Overhaul for the change in direction on 1237.
> Improve permissions to allow control over creation/removal/listing of
> Keyspaces
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-1271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 0.7.0
>
>
> We'd like to improve resources/permissions so that they can be applied to the
> global scope, instead of just individual keyspaces.
> IAuthority currently only has one concept of a resource that it can authorize
> for: a keyspace. At the very least, this ticket needs to deal with one
> additional resource: "the keyspace list". These resources should be mapped
> into a hierarchy, and an object representing the path to the resource will be
> passed to IAuthority.
> A resource hierarchy to represent all possible resources in Cassandra might
> look like: {{/cassandra/<cluster_name>/keyspaces/<ks_name>/...}}
> In table form:
> || resource || checked perms || explanation ||
> | /cassandra/ | n/a | Separates Cassandra-internal resources from resources
> that might be provided by plugins. |
> | <cluster_name>/ | n/a | Organizations might have many clusters |
> | keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
> resource mean the ability to view/modify the list of keyspaces. |
> | <ks_name>/ | READ, WRITE, MODIFY_SCHEMA | An individual keyspace: since
> this is the last entry in the current hierarchy, READ/WRITE apply recursively
> to ancestor _data_ of the keyspace, while FULL applies recursively to
> ancestor _schemas_ of the keyspace. |
> (Note that {{/cassandra/}} and {{<cluster_name>/}} will not yet be checked
> for permissions via a call to IAuthority.authorize, so while it would be
> possible for an IAuthority backend to store permissions for these top level
> resources, they will only be able to deny access when a user attempts to
> access an ancestor resource.)
> Over time Cassandra _may_ add additional authorize calls for resources higher
> or lower in the chain, which IAuthority backends can choose to ignore, but
> this initial patch will only make authorize calls for the keyspaces list, and
> individual keyspaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
