[jira] [Commented] (CASSANDRA-8303) Provide "strict mode" for CQL Queries

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266101#comment-14266101 ] 

Sam Tunnicliffe commented on CASSANDRA-8303:
--------------------------------------------

It seems to me that this could be a reasonably natural fit as an extension to the existing authz system. If we do go down that route there are a couple of things to consider. 

What we're really talking about here are restrictions on the permissions a particular user may have been granted. For instance, you could grant SELECT on ks1.cf1 to user foo, but add a restriction such that multipartition queries are not allowed. My first question then is are there other restrictions that would be useful but which don't fit this definition?

For restrictions which do fit that definition, it seems sensible to use a similar resource hierarchy as permissions. i.e. a restriction can be applied at the table level, keyspace level (which trickles down to apply to all tables in the ks), or at the root level. The alternative implied by the syntax in the previous comments suggests that a restriction should always be applied at the root level (i.e. for all keyspaces & tables). 

How inheritance is handled in that hierarchy of resources should be from the bottom upwards, working from the most specific permission/restriction.For instance, in the case where user x is granted SELECT without any restriction on ks1 and the same user is also granted SELECT with the MULTI_PARTITION restriction on ks1.cf1 it seems clear that MP queries from user x should only be disallowed on the one table, not all tables in ks1. Also, the unrestricted grant should not trump the more specific, restricted one and allow MP queries on that table.
In the reverse scenario, where the restriction is at the keyspace level, but there is also a non-restricted grant for the table, the behaviour should also be reversed, user x can make MP queries on the 1 table, but on no others in the keyspace.

As noted, managing all this at the user level could be overly burdensome but CASSANDRA-7653 should relieve most of that extra administrative load. However, it would involve some additional complexity in handling resolution of permissions and restrictions.

During the authz process when we resolve permissions for a user on a particular resource, the most specific permission whether granted directly or inherited through role membership should apply, along with any of its restrictions. If there are multiple inherited or direct grants for the exact same resource (i.e. at the same level in the resource hierarchy) then we would merge them, unioning any restrictions, e.g

{noformat}
role x is granted SELECT on ks1 with MULTI_PARTITION restriction
role y is granted SELECT on ks1.cf1, unrestricted
role y should be allowed to SELECT from any table in ks1, but perform MP queries on ks1.cf1 only 

role z is granted both role x and role y
role z should be allowed to SELECT from any table in ks1, but perform MP queries on ks1.cf1 only 

role a is granted SELECT on ks1, unrestricted
role z is granted roles x, y, a
role z should be allowed to SELECT from any table in ks1, but perform MP queries on ks1.cf1 only 
{noformat}

So, I think this could fit nicely into authz for 3.0 but we may also want to think about adding options to cassandra.yaml to enforce the same restrictions without requiring authz (& authn). Obviously, that would be much more of a blunt instrument - enforcing a given restriction for all queries when enabled, though it would mean that it could be turned on on a per-node/per-DC basis. I don't see a problem with supporting both cql and yaml based approaches so long as we define an order of precedence.

> Provide "strict mode" for CQL Queries
> -------------------------------------
>
>                 Key: CASSANDRA-8303
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Anupam Arora
>             Fix For: 3.0
>
>
> Please provide a "strict mode" option in cassandra that will kick out any CQL queries that are expensive, e.g. any query with ALLOWS FILTERING, multi-partition queries, secondary index queries, etc.



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