incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <robin....@bluecoat.com>
Subject RE: Re: bandwidth limiting Cassandra's replication and access control
Date Wed, 11 Nov 2009 22:46:51 GMT
Well, I started out by saying that I'm a complete Cassandra newbie, so I may not understand
just how exposed my data may be.

Please correct me if I misunderstood but can't I secure Cassandra against unauthorized access
by attaching my Thrift listener to my internal adapter address?  If that's the case, then
is it not so that an unauthorized user who knew the IP of a server on which Cassandra is running,
and also knew the Keyspace, couldn't create their own client to access my data.  Am I wrong
in that assumption?

My normal take on security is to protect the physical server, make the data store unavailable
on a private network, then provide access to those data via an application service.  Does
that model not work with Cassandra?

Are there security concerns exposed by the replication services between instances, because
of the need for public ports?

Thanks,
Robin.

-----Original Message-----
From: Jonathan Ellis [mailto:jbellis@gmail.com] 
Sent: November 11, 2009 5:26 PM
To: cassandra-user@incubator.apache.org; cassandra-dev@incubator.apache.org
Subject: Re: Re: bandwidth limiting Cassandra's replication and access control

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