incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Subrahmanya Harve <subrahmanyaha...@gmail.com>
Subject Re: Queries on AuthN and AuthZ for multi tenant Cassandra
Date Thu, 02 Feb 2012 21:00:40 GMT
Thank you.
Is that true for 0.8.7 as well?


On Thu, Feb 2, 2012 at 8:20 AM, Jeremiah Jordan <
JEREMIAH.JORDAN@morningstar.com> wrote:

> 10-15 KS should be fine.  The issue is when you want to have hundreds or
> thousands of KS/CF.
>
> -Jeremiah
>
> -----Original Message-----
> From: Subrahmanya Harve [mailto:subrahmanyaharve@gmail.com]
> Sent: Thursday, February 02, 2012 1:43 AM
> To: dev@cassandra.apache.org
> Subject: Re: Queries on AuthN and AuthZ for multi tenant Cassandra
>
> Thanks for the response Aaron.
>
> We do not anticipate more than 10-15 tenants on the cluster. Even if one
> does decide to create one KS/tenant, there is the problem of variable
> loads
> on the KS's. I went through this link
> http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-mem
> ory-and-disk-space-managementwhich
> does promise better memory management. I did have two more questions
> -
> - Was the new memory management written taking into account a situation
> of
> many KS's? (In other words, did multi-tenancy influence the re-design of
> memory management?)
> - i know that users trying out multi-tenancy are generally recommending
> not
> to create many Ks's/CF's, but i am wondering if there is any
> documentation
> for why this happens or the details on the negative impact on
> memory/performance?and are there are any performance benchmarks
> available
> for Cassandra 1.0 clusters with many KS's?
>
>
> On Wed, Feb 1, 2012 at 12:11 PM, aaron morton
> <aaron@thelastpickle.com>wrote:
>
> > 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.
> >
> > Cheers
> >
> >
> > -----------------
> > Aaron Morton
> > Freelance Developer
> > @aaronmorton
> > http://www.thelastpickle.com
> >
> > 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 -
> > > http://www.datastax.com/docs/0.8/configuration/authentication , 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
> > >
> >
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Re-Mult
> i-tenancy-and-authentication-and-authorization-td5935230.htmland<http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Re-Mult%0Ai-tenancy-and-authentication-and-authorization-td5935230.htmland>
> > > 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
> > > https://issues.apache.org/jira/browse/CASSANDRA-2006resolved, 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)
> >
> >
>

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