incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <>
Subject RE: bandwidth limiting Cassandra's replication and access control
Date Thu, 12 Nov 2009 02:38:22 GMT
Ok, this makes sense.  I was looking at this as a real security service
but I think I understand where you're going with this.  Again, forgive
me for being a Cassandra newb.

If the idea is to add a per-keyspace token in the storage.conf and open 
the thrift connection using that token, then I agree, this would be a 
pretty simple solution and not a performace hit.

Have I finally understood the proposal?


-----Original Message-----
From: Jonathan Ellis []
Sent: Wed 11/11/2009 18:26
Subject: Re: bandwidth limiting Cassandra's replication and access control
On Wed, Nov 11, 2009 at 8:17 PM, Coe, Robin <> wrote:
> I completely agree with Ian but would also like to add a point about the
> proposed service.  As was presented, the authentication is to be performed
> at the Thrift API layer, not the CLI layer.  In a relational database
> environment, this would be equivalent to connections opened over a
> network.  In this environment, all connections share the same user account,
> which is not per-user authentication.

As Ian points out, most applications get by fine with a single user.
So keyspace auth provides app level auth, not really user-level.
Which is a great 80% solution.  (Really more like 95% I would say.)

> I would still like to understand why there is the need to impose a keyspace
> binding, from a security standpoint.

You don't want any app to be able to accidentally or maliciously touch
another's data.  Jonathan Mischo gave a bunch of excellent reasons why
this is so.

> Beyond that, how will tokens be shared amongst all
> the nodes in a cluster

they don't need to be.

> such that a user returning to a different node
> maintains the keyspace binding and do so without affecting performance?

We're only trying to provide authentication, not some cross-connection
session.  Each connection will authenticate individually.

/gave up on trying to move this to -dev

View raw message