[
https://issues.apache.org/jira/browse/CASSANDRA-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremiah Jordan updated CASSANDRA-13985:
----------------------------------------
Description:
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.
UPDATE:
The approach taken in this ticket was to setup access for a given user to a set
of DC. A user can either login and run queries in a given DC or they can not.
The ROLE statements were updated:
{code}
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS
TO DATACENTERS {'DC1', 'DC3'};
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS
TO ALL DATACENTERS;
{code}
was:
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.
> Support restricting access 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: Low
> Fix For: 4.0, 4.0-alpha1
>
>
> 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.
> UPDATE:
> The approach taken in this ticket was to setup access for a given user to a
> set of DC. A user can either login and run queries in a given DC or they can
> not. The ROLE statements were updated:
> {code}
> CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND
> ACCESS TO DATACENTERS {'DC1', 'DC3'};
> CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND
> ACCESS TO ALL DATACENTERS;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
