[
https://issues.apache.org/jira/browse/CASSANDRA-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996323#comment-13996323
]
Aleksey Yeschenko commented on CASSANDRA-7216:
----------------------------------------------
I see what you want and why you want it. That said, I'm not sure it's a common
enough/important enough use-case, that can't be worked around, to go break the
IAuth* APIs.
So, in either case you do need both the ability to create new keyspaces (for
new tenants) and create new users that can access them (for the tenants, too).
Are you sure you absolutely can't have just one single, tightly controlled
super user in the system for both purposes? B/c even if you have a restricted
super user for user creation, you'd still need to create a keyspace for them
anyway (although you don't need a superuser for that, indeed, just someone with
CREATE ON ALL KEYSPACES).
> Restricted superuser account request
> ------------------------------------
>
> Key: CASSANDRA-7216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7216
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Oded Peer
> Priority: Minor
>
> I am developing a multi-tenant service.
> Every tenant has its own user, keyspace and can access only his keyspace.
> As new tenants are provisioned there is a need to create new users and
> keyspaces.
> Only a superuser can issue CREATE USER requests, so we must have a super user
> account in the system. On the other hand super users have access to all the
> keyspaces, which poses a security risk.
> For tenant provisioning I would like to have a restricted account which can
> only create new users, without read access to keyspaces.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
