[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243985#comment-16243985
]
Sam Tunnicliffe commented on CASSANDRA-13985:
---------------------------------------------
In general I agree with the aim of this ticket, but I think perhaps we should
come at it from a different angle.
First, DCs don't fit well into the authz model as it's defined currently, with
Roles, Resources & Permissions, so we have to extend that model and make DC a
first class citizen. I don't think this is huge problem in itself, but it
follows that if we do that we should do the same for Capabilities as proposed
in CASSANDRA-8303. I appreciate that that ticket is still in discussion and
also hasn't moved in quite a while, but I do think it's still worth doing and
plan/hope to get back to it soon. Adding another component to either of those
models is
Second, I'm not altogether convinced that having a given user's permissions (or
capabilities) modified by DC is the right way to go. Having varying privileges
dependent on which coordinator you happen to be connected to seems like it
could end up being a bit counter-intuitive. My feeling is that it makes more
sense to control whether a role is permitted to access a location at all. If
so, then normal permissions should apply.
Third, I'm not a big fan of the implicit granting by omission, even though it's
more or less consistent with the way permissions work, it somehow feels kind of
jarring here (but I'm afraid I'm struggling to articulate exactly why).
These things make me think that this might be better implemented as an entirely
separate feature, distinct from permissions and capabilities. Rather than
adding complexity by extending those models we could add a new thing which
simply bans a user from connecting to nodes in a given DC or blocks execution
of CQL statements for already connected clients. This would be really simple to
implement and would provide better separation from the code and concepts of
permissions and capabilities.
> Support restricting reads and writes to specific datacenters on a per user
> basis
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-13985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13985
> Project: Cassandra
> Issue Type: Bug
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Minor
>
> There are a few use cases where it makes sense to restrict the operations a
> given user can perform in specific data centers. The obvious use case is the
> production/analytics datacenter configuration. You don’t want the production
> user to be reading/or writing to the analytics datacenter, and you don’t want
> the analytics user to be reading from the production datacenter.
> Although we expect users to get this right on that application level, we
> should also be able to enforce this at the database level. The first approach
> that comes to mind would be to support an optional DC parameter when granting
> select and modify permissions to roles. Something like {{GRANT SELECT ON
> some_keyspace TO that_user IN DC dc1}}, statements that omit the dc would
> implicitly be granting permission to all dcs. However, I’m not married to
> this approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
