cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: bandwidth limiting Cassandra's replication and access control
Date Thu, 12 Nov 2009 02:43:57 GMT
That's the essential idea, although I think Ted's hoping to make it
configurable to talk to other auth providers as well.

On Wed, Nov 11, 2009 at 8:38 PM, Coe, Robin <robin.coe@bluecoat.com> wrote:
> 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:jbellis@gmail.com]
> Sent: Wed 11/11/2009 18:26
> To: cassandra-user@incubator.apache.org
> Subject: Re: bandwidth limiting Cassandra's replication and access control
>
> On Wed, Nov 11, 2009 at 8:17 PM, Coe, Robin <robin.coe@bluecoat.com> 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
>
>

Mime
View raw message