incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Re: bandwidth limiting Cassandra's replication and access control
Date Wed, 11 Nov 2009 22:26:16 GMT
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.coe@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:driftx@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.coe@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

Mime
View raw message