[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444935#comment-16444935
]
Blake Eggleston commented on CASSANDRA-13985:
---------------------------------------------
pushed an updated branch
[here|https://github.com/bdeggleston/cassandra/tree/13985-v2], corresponding
dtest branch
[here|https://github.com/bdeggleston/cassandra-dtest/tree/13985-v2], and the
[tests|https://circleci.com/workflow-run/caecca68-6dcc-4a4a-84fc-5eb6083825c0].
Some notes / responses:
* I prefer your version of the syntax. Set literal syntax is familiar, and it's
clearer what it is you're doing, although slightly more verbose.
* I went with throwing a configuration exception on startup if you have a
nonsensical config.
* Regarding re-using the cache, I'd prefer sharing config with the RolesCache.
Even though they're separate systems under the hood, they're sort of exposed as
part of the same system through the DCL.
* I've reverted the changes to CREATE/ALTER USER statements
> 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: Improvement
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Minor
> Fix For: 4.0
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
