[ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Strickland updated CASSANDRA-12859: ------------------------------------------ Description: h4. Here is a draft of: Cassandra Proposal - Column-level permissions.docx (attached) h4. 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. h4. 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. h4. Main day-one requirements # 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. # Persist the optional information in the appropriate system table ‘system_auth.role_permissions’. # 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 # Reflect the column-level permissions in statements of type LIST ALL PERMISSIONS OF someuser; # Performance should not degrade in any significant way. # 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. h4. Documentation * https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission * Feedback request: any others? was: h4. Here is a draft of: Cassandra Proposal - Column-level permissions.docx (attached) h4. 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. h4. 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. h4. Main day-one requirements # 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. # Persist the optional information in the appropriate system table ‘system_auth.role_permissions’. # 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 # Reflect the column-level permissions in statements of type LIST ALL PERMISSIONS OF someuser; # Performance should not degrade in any significant way. # 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. h4. Documentation * https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission * Feedback request: any others? > 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 > > h4. Here is a draft of: > Cassandra Proposal - Column-level permissions.docx (attached) > h4. 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. > h4. 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. > h4. Main day-one requirements > # 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. > # Persist the optional information in the appropriate system table > ‘system_auth.role_permissions’. > # 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 > # Reflect the column-level permissions in statements of type > LIST ALL PERMISSIONS OF someuser; > # Performance should not degrade in any significant way. > # 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. > h4. Documentation > * > https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission > * Feedback request: any others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)