[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&focusedCommentId=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&focusedCommentId=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&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: 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&focusedCommentId=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&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: 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&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
[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&focusedCommentId=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