[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447929#comment-16447929
]
Sam Tunnicliffe commented on CASSANDRA-13985:
-
LGTM, +1
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16446467#comment-16446467
]
Blake Eggleston commented on CASSANDRA-13985:
-
got all of the tests passing:
https://circleci.com/workflow-run/7c339d36-2dcd-4a38-9020-bb629b4880a0
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444772#comment-16444772
]
Ariel Weisberg commented on CASSANDRA-13985:
There was a mixup and Blake kept working on it. So at this point I'll just
leave it to Blake.
> 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: Ariel Weisberg
>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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443107#comment-16443107
]
Sam Tunnicliffe commented on CASSANDRA-13985:
-
I like this approach, it's pretty much exactly how I was thinking this ought to
work. Also, I think it's a good idea to extend {{CREATE/ALTER ROLE}} rather
than adding new and potentially unwieldy DCL statements. If you don't mind, I'd
like to bikeshed the syntax a little though... although functionally equivalent
to what you have, how do you feel about:
{code:java}
1. CREATE ROLE WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO
DATACENTERS {'dc1', 'dc2', 'dc3'};
2. CREATE ROLE WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO
DATACENTERS {'dc1'};
3. CREATE ROLE WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO ALL
DATACENTERS;
4. CREATE ROLE WITH LOGIN=true AND PASSWORD='***';
5. ALTER ROLE WITH ACCESS TO DATACENTERS {'dc1', 'dc2', 'dc3'};
6. ALTER ROLE WITH ACCESS TO ALL DATACENTERS;
{code}
As currently, in each variant the order of the role attributes is not fixed.
Maybe we could live without 3. as 3. & 4. are equivalent. On the one hand it
feels like we ought to support it because it's explicit, but on the other it's
redundant/verbose.
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.
I have just a couple of other small things:
* We should clean up network permissions on DROP ROLE like we do resource
permissions
* It's possible to specify DC permissions in ALTER/CREATE ROLE statements
regardless of the configured {{INetworkAuthorizer}}. If
{{AllowAllNetworkAuthorizer}} is used, clauses are silently ignored. This is
different from other auth statements, so maybe we need an equivalent to
{{IAuthenticator::requireAuthentication}} /
{{IAuthorizer::requireAuthorization}} (we only need check it when modifying
role perms.
* This changes existing behaviour when a role is altered to remove the LOGIN
privilege. Previously, existing connections would continue to function but now
the check in validateLogin blocks them immediately. Personally, I think this is
an improvement and we're targetting a major so I guess we're fine but we should
make a note to include this in NEWS.txt.
* Should we warn at startup if authentication is not enabled, but network
authorization is?
* The other pluggable auth components specify a {{validateConfig}} hook,
called from {{AuthConfig}}, which is a noop in all the internal
implementations. Might be good for extensibility to add that to
{{INetworkAuthorizer}}.
* {{NetworkAuthCache}} reuses the caching settings of {{RoleCache}}, although
it makes sense that they're aligned maybe changing one via JMX and having the
other be affected could be counter-intuitive. I'm a bit torn on this one
between least surprise and making life easier for operators.
* CQL docs and auto completion need updating
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440129#comment-16440129
]
Ariel Weisberg commented on CASSANDRA-13985:
The dtests aren't there right now.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297580#comment-16297580
]
Blake Eggleston commented on CASSANDRA-13985:
-
I pushed up a branch with a different approach
[here|https://github.com/bdeggleston/cassandra/tree/13985-v2], and some
associated dtests
[here|https://github.com/bdeggleston/cassandra-dtest/tree/13958-v2].
In this version, datacenter permissions are associated with a single user role,
they're not inherited through the role hierarchy or anything. They're stored in
their own table, but are administered through the existing CREATE/ALTER
USER/ROLE statements. By default, a user has access to all dcs unless
configured otherwise.
> 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
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279342#comment-16279342
]
Blake Eggleston commented on CASSANDRA-13985:
-
Coming back to this, I think that the implicit granting by omission seems like
the least bad option. Basically wildcard by default. I expect the most common
use case will be to confine a user to a single data center. So I’m looking at
this this from the perspective of making that easy to achieve.
I don’t think implementing this as a straight up whitelist would work because
it creates a chicken and egg problem of turning on the authz feature and being
able to connect to it and configure it. Also, if you’re only interested in
confining a subset of all your users, it becomes difficult to administer. On
the other hand, a black list would add the overhead of having to go and update
each restricted role any time a dc is added. Obviously it’s not something that
happens often, but I don’t think we need to add another detail that needs to be
worried about (and easily overlooked) if we can avoid it.
> 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
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244367#comment-16244367
]
Blake Eggleston commented on CASSANDRA-13985:
-
I agree that tacking this onto the existing permission system is a little
hacky. Adding this as a separately managed control makes sense.
The reason I was playing around with extending the existing hooks, vs adding a
new one was because of ui reasons. Today we have grant and revoke statements,
8303 will add create/drop restriction statements, this will probably add a
statement for DCs, and I won’t be surprised if we see a rate/resource
limitation thing get requested in the future. Depending on how this gets
implemented, the cql statements behind it will probably overlap with either
grant/revoke or create/drop restriction.
Maybe this isn’t that big of a deal though. If that’s the case, mapping
statements to different controls under the hood wouldn't be too difficult.
> 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
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244121#comment-16244121
]
Sam Tunnicliffe commented on CASSANDRA-13985:
-
Postgres has something vaguely similar in its {{pg_hba.conf}}, which lets you
restrict whether clients can connect based on various criteria such as user,
host, ip range, etc. To block a user/role entirely you would just remove all of
its entries in the config file. It's not directly analogous as postgres also
supports multiple authn methods and obviously isn't distributed so the
restrictions apply to the single db server, but it is separating the access to
the service itself from the specifics of auth(n|z).
> 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
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243207#comment-16243207
]
Blake Eggleston commented on CASSANDRA-13985:
-
Here’s an initial implementation optionally add specific datacenters when
granting permissions: https://github.com/bdeggleston/cassandra/tree/13985
> 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
