[CASSANDRA-12859] Column-level permissions

• Type: New Feature
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Component/s: Legacy/Core, Legacy/CQL
• Labels: doc-impacting
• Assignee: Unassigned
• Reporter: Boris Melamed
• Created: 28/Oct/16 14:56
• Updated: 16/Apr/19 09:30

Description

Here is a draft of:

Cassandra Proposal - Column-level permissions.docx (attached)

Quoting the 'Overview' section:

The purpose of this proposal is to add column-level (field-level) permissions to Cassandra. It is my intent to soon start implementing this feature in a fork, and to submit a pull request once it’s ready.

Motivation

Cassandra already supports permissions on keyspace and table (column family) level. Sources:

• http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
• https://cassandra.apache.org/doc/latest/cql/security.html#data-control

At IBM, we have use cases in the area of big data analytics where column-level access permissions are also a requirement. All industry RDBMS products are supporting this level of permission control, and regulators are expecting it from all data-based systems.

Main day-one requirements

1. Extend CQL (Cassandra Query Language) to be able to optionally specify a list of individual columns, in the GRANT statement. The relevant permission types are: MODIFY (for UPDATE and INSERT) and SELECT.
2. Persist the optional information in the appropriate system table ‘system_auth.role_permissions’.
3. Enforce the column access restrictions during execution. Details:
   • Should fit with the existing permission propagation down a role chain.
   • Proposed message format when a user’s roles give access to the queried table but not to all of the selected, inserted, or updated columns:
     "User %s has no %s permission on column %s of table %s"
   • Error will report only the first checked column.
     Nice to have: list all inaccessible columns.
   • Error code is the same as for table access denial: 2100.

Additional day-one requirements

1. Reflect the column-level permissions in statements of type
   LIST ALL PERMISSIONS OF someuser;
2. When columns are dropped or renamed, trigger purging or adapting of their permissions
3. Performance should not degrade in any significant way.
4. Backwards compatibility
   • Permission enforcement for DBs created before the upgrade should continue to work with the same behavior after upgrading to a version that allows column-level permissions.
   • Previous CQL syntax will remain valid, and have the same effect as before.

Documentation

• https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission
• Feedback request: any others?

Issue Links

• is duplicated by: CASSANDRA-13036 Row and Cell Level Authorisation