[ 
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Strickland updated CASSANDRA-12859:
------------------------------------------
    Attachment: Cassandra Proposal - Column-level permissions.docx

> Column-level permissions
> ------------------------
>
>                 Key: CASSANDRA-12859
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core, CQL
>            Reporter: Boris Melamed
>         Attachments: Cassandra Proposal - Column-level permissions.docx
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Here is a draft of: 
> Cassandra Proposal - Column-level permissions.docx
> https://ibm.box.com/s/ithyzt0bhlcfb49dl5x6us0c887p1ovw
> 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:
>   a.  Should fit with the existing permission propagation down a role chain.
>   b.  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"
>   c.  Error will report only the first checked column. 
> Nice to have: list all inaccessible columns.
>   d.  Error code is the same as for table access denial: 2100.
> Additional day-one requirements
> 4.    Reflect the column-level permissions in statements of type 
> LIST ALL PERMISSIONS OF someuser;
> 5.    Performance should not degrade in any significant way.
> 6.    Backwards compatibility
>   a.  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.
>   b.  Previous CQL syntax will remain valid, and have the same effect as 
> before.
> 7.    Documentation
>   o   
> https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission
>   o   Feedback request: any others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to