cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13985) Support restricting reads and writes to specific datacenters on a per user basis
Date Wed, 18 Apr 2018 20:00:00 GMT

    [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message