[
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)
