The main reason we support multiple keyspaces is to allow separation of different applications. So within a keyspace, the app should manage permissions, but at the keyspace level Cassandra should be in charge.
On Wed, Nov 11, 2009 at 4:18 PM, Coe, Robin <robin....@bluecoat.com> wrote: > Do you mean that users interacting with Cassandra through the CLI should be > restricted based on a security service? I agree. However, I believe the > more common case is to front the Cassandra service with an application > layer, as you would expose a relational backend. For that kind of service, > the application should control the security. > > > > Basically, a user request to Cassandra is not stateful; any request should > be able to perform a transaction against any node in the cluster, using an > appropriate consistency model for the request. Requiring something like > real time token synchronization across all nodes in a cluster seems outside > of Cassandra’s eventual consistency model. > > > > Securing the data is intrinsically application-specific. While I could see > adding a plugin that makes the CLI access point secured, I would still want > that to be made in a pluggable fashion, so it could be swapped out with a > custom implementation. > > > > Of course, this is just my point of view, but I make it after having written > several security layers on J2EE apps over the years and none of them have > been the same. Besides that, I want the data layer to be highly efficient > and in my opinion, it isn’t the work of the data service to impose security. > > > > Robin. > > > > From: Brandon Williams [mailto:dri...@gmail.com] > Sent: November 11, 2009 4:44 PM > To: cassandra-user@incubator.apache.org > Subject: Re: Re: bandwidth limiting Cassandra's replication and access > control > > > > On Wed, Nov 11, 2009 at 9:40 AM, Coe, Robin <robin....@bluecoat.com> wrote: > > IMO, auth services should be left to the application layer that interfaces > to Cassandra and not built into Cassandra. In the tutorial snippet included > below, the access being granted is at the codebase level, not the > transaction level. Since users of Cassandra will generally be fronted by a > service layer, the java security manager isn’t going to suffice. What this > snippet could do, though, and may be the rationale for the request, is to > ensure that unauthorized users cannot instantiate a new Cassandra server. > However, if a user has physical access to the machine on which Cassandra is > installed, they could easily bypass that layer of security. > > > > What if Cassandra IS the application you're exposing? Imagine a large > company that creates one large internal Cassandra deployment, and has > multiple departments it wants to create separate keyspaces for. You can do > that now, but there's nothing except a gentlemen's agreement to prevent one > department from trashing another department's keyspace, and accidents do > happen. You can front the service with some kind of application layer, but > then you have another API to maintain, and you'll lose some performance this > way. > > > > -Brandon
