[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Melamed updated CASSANDRA-12859:
--
Attachment: Cassandra Proposal - Column-level permissions v2.docx
All changes are tracked, for easier review.
Main changes and decisions since v0.1:
1. Incorporated feedback from Sam Tunnicliffe: DELETE/TRUNCATE, cleanup,
unit tests, ...
2. Added a clarifying section "Some details on permission lifecycle and
precedence" to "Overview".
3. Regarding grammar of GRANT, opted for (A), the more standard 'GRANT
SELECT(c1, c2) ON ks.t1 TO role1'.
4. Slight modification to persisting column sets, see Option B' on page 8.
5. Granting permissions on columns is additive, not replacing. This may
indeed be more intuitive. For now, however, one cannot specify columns on
REVOKE. Therefore, the only way to revoke a column permission is to revoke that
permission on the whole table and then to grant the permission on the
previously included columns except c1.
> 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
> Labels: doc-impacting
> Attachments: Cassandra Proposal - Column-level permissions v2.docx,
> 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.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their
> permissions
> # 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)
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Melamed updated CASSANDRA-12859:
--
Labels: doc-impacting (was: )
> 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
> Labels: doc-impacting
> 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.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their
> permissions
> # 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)
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Melamed 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.
h4. Additional day-one requirements
# Reflect the column-level permissions in statements of type
{{LIST ALL PERMISSIONS OF someuser;}}
# When columns are dropped or renamed, trigger purging or adapting of their
permissions
# 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.
h4. 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
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[
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.
h4. 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
>
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[
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:
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[ 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: 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: 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? > Column-level permissions > > > Key:
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Strickland updated CASSANDRA-12859: -- 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: 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? was: 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
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[ 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:
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[ 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:
[jira] [Updated] (CASSANDRA-12859) Column-level permissions
[ 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)
