[ 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 <role> WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO DATACENTERS {'dc1', 'dc2', 'dc3'}; 2. CREATE ROLE <role> WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO DATACENTERS {'dc1'}; 3. CREATE ROLE <role> WITH LOGIN=true AND PASSWORD='***' AND ACCESS TO ALL DATACENTERS; 4. CREATE ROLE <role> WITH LOGIN=true AND PASSWORD='***'; 5. ALTER ROLE <role> WITH ACCESS TO DATACENTERS {'dc1', 'dc2', 'dc3'}; 6. ALTER ROLE <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