[
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: [email protected]
For additional commands, e-mail: [email protected]
