incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <>
Subject Re: Queries on AuthN and AuthZ for multi tenant Cassandra
Date Wed, 01 Feb 2012 20:11:13 GMT
The existing authentication plug-in does not support row level authorization. 

You will need to add authentication to your API layer to ensure that a request from client
X always has the client X key prefix. Or modify cassandra to provide row level authentication.

The 1.x Memtable memory management is awesome, but I would still be hesitant about creating
KS's and CF's at the request of an API client.


Aaron Morton
Freelance Developer

On 2/02/2012, at 8:52 AM, Subrahmanya Harve wrote:

> We are using Cassandra 0.8.7 and building a multi-tenant cassandra platform
> where we have a common KS and common CFs for all tenants. By using Hector's
> virtual keyspaces, we are able to add modify rowkeys to have a tenant
> specific id. (Note that we do not allow tenants to modify/create KS/CF. We
> just allow tenants to write and read data) However we are in the process of
> adding authentication and authorization on top of this platform such that
> no tenant should be able to retrieve data belonging to any other tenant.
> By configuring Cassandra for security using the documentation here -
> , we were
> able to apply the security constraints on the common keyspace and common
> CFs. However this does not prevent a tenant from retrieving data belonging
> to another tenant. For this to happen, we would need to have separate CFs
> and/or keyspaces for each tenant.
> Looking for more information on the topic here
> other places, it looks like the recommendation is "not" to create
> separate CFs and KSs for every tenant as this would have impacts on
> Memtables and other memory issues. Does this recommendation still hold
> good?
> With jiras like
>, does it
> mean we can now create multiple (but limited) CFs and KSs?
> More generally, how do we prevent a tenant from intentional/accidental data
> manipulation of data owned by another tenant? (given that all tenants will
> provide the right credentials)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message