cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <>
Subject RE: Re: bandwidth limiting Cassandra's replication and access control
Date Wed, 11 Nov 2009 22:18:18 GMT
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.




From: Brandon Williams [] 
Sent: November 11, 2009 4:44 PM
Subject: Re: Re: bandwidth limiting Cassandra's replication and access


On Wed, Nov 11, 2009 at 9:40 AM, Coe, Robin <>

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.



View raw message