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? Robin. -----Original Message----- From: Jonathan Ellis [mailto:[email protected]] Sent: Wed 11/11/2009 18:26 To: [email protected] Subject: Re: bandwidth limiting Cassandra's replication and access control On Wed, Nov 11, 2009 at 8:17 PM, Coe, Robin <[email protected]> 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. -Jonathan /gave up on trying to move this to -dev
<<winmail.dat>>
