[CASSANDRA-1271] Improve permissions to allow control over creation/removal/listing of Keyspaces

• Type: Improvement
• Status: Resolved
• Priority: Low
• Resolution: Fixed
• Fix Version/s: 0.7 beta 3
• Assignee: Eric Evans
• Reporter: Stu Hood

Authors

Eric Evans

Reviewers

Eric Evans

• Created: 12/Jul/10 22:20
• Updated: 16/Apr/19 09:33
• Resolved: 28/Sep/10 23:12

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, READ_VALUE, WRITE_VALUE	An individual keyspace: READ/WRITE mean the ability to view/modify the list of column families. Since this is the last entry in the current hierarchy, READ/WRITE_VALUE apply recursively to ancestor data of this keyspace.

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. As authorize calls are added for child resources like <cf_name>/, the READ/WRITE_VALUE permissions will move to the lowest checked level, and will be deprecated at higher levels.

(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.)

Issue Links

• is blocked by: CASSANDRA-1320 Convert AccessLevel to Set<Permission>
• relates to: CASSANDRA-1554 extend authorization to column families