[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444694#comment-16444694
]
Ariel Weisberg commented on CASSANDRA-13985:
--------------------------------------------
RE: Added syntax
Philosophically I want there to be the minimum number of ways to accomplish
something. The fact that it's default open to all data centers is a bit
sketchy. But the situation we are in is that we probably shouldn't start
requiring people to add "ACCESS TO ALL DATACENTERS" so if we only want one way
then it's just #4.
AND ACCESS TO DATA CENTERS vs WITH DATACENTERS I don't have a strong
preference, but more succinct is better since it is easier to remember. I think
listing the DCs as a sequence of ORs is a bit awkward so I am on board with
that change.
bq. I'm also not sure whether we should bother updating CREATE/ALTER USER.
They're basically deprecated and just support a subset of the role management
statements, i.e. no support for OPTIONS or LOGIN. I won't argue though if we do
want to add this to them.
[~bdeggleston] if it's deprecated I would like to leave this functionality out
to further discourage people from continuing to use it. The less it appears in
the wild the better.
bq. Should we warn at startup if authentication is not enabled, but network
authorization is?
Warn or fail to start? This seems like someone is asking for something
nonsensical and when it comes to authz fail closed is the best thing to do
right?
Looking into the rest of the feedback deeper now, but most of it makes sense to
me.
> 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]
