Return-Path: 
 <cassandra-user-return-1221-apmail-incubator-cassandra-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org
Received: (qmail 87855 invoked from network); 11 Nov 2009 22:27:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 11 Nov 2009 22:27:06 -0000
Received: (qmail 13662 invoked by uid 500); 11 Nov 2009 22:27:05 -0000
Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org
Received: (qmail 13624 invoked by uid 500); 11 Nov 2009 22:27:05 -0000
Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cassandra-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:cassandra-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:cassandra-user@incubator.apache.org>
List-Id: <cassandra-user.incubator.apache.org>
Reply-To: cassandra-user@incubator.apache.org
Delivered-To: mailing list cassandra-user@incubator.apache.org
Received: (qmail 13607 invoked by uid 99); 11 Nov 2009 22:27:05 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 22:27:05 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=FS_REPLICA,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 209.85.220.214 as permitted sender)
Received: from [209.85.220.214] (HELO mail-fx0-f214.google.com)
 (209.85.220.214)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 22:26:57 +0000
Received: by fxm6 with SMTP id 6so1368396fxm.20
        for <multiple recipients>; Wed, 11 Nov 2009 14:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :from:date:message-id:subject:to:content-type
         :content-transfer-encoding;
        bh=pHnd1fgbGYH/vIVy1VoCQpjma2BlUDjVr479aBDnNTs=;
        b=rI6PGc3CatHrTMXoSNkfy6uW84kmrB7fLscBQ8HMv+G4Xfdxb9oYenOW+y3XmABKZU
         u96VepzlwMpyH82Ybh1LFt3B/sSL6deHeSMQGDK+wVclXbQDahlP70pVRocp6b3aPXrz
         wuWT84zcIwxCt85IINfhD49S9CZqFwJDGsv1o=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=B5YgDV2VnSZS1n5ayWf0FnahWXm3pKTpgWTWGp6sfokCqgV9jKybXJvhB6E1WdXN47
         3fegVGEoxZ49g6AZgi1yLxKpD6CTWsKeiVffltprzt1NczvqB6HcMmJA0J9T98rx1ZS2
         GTKywMQ9lhvTn9yTe9jFpigNvFzWoCwyYQSG0=
MIME-Version: 1.0
Received: by 10.216.89.141 with SMTP id c13mr426438wef.66.1257978396297; Wed,
	11 Nov 2009 14:26:36 -0800 (PST)
In-Reply-To: 
 <764B352CF55C514F816B4B14BD2450D803DBBF2C@bcs-mail04.internal.cacheflow.com>
References: <87eio6p7pb.fsf@lifelogs.com>
 <e06563880911101153j60552e58h417fe8f896ca6ce@mail.gmail.com>
	<87ljienhjx.fsf@lifelogs.com>
 <e06563880911101509t7b457941q49394a000f6e639c@mail.gmail.com>
	<87hbt1nnur.fsf@lifelogs.com>
 <764B352CF55C514F816B4B14BD2450D803DBB97B@bcs-mail04.internal.cacheflow.com>
	<cdc5ad200911111344v38c44732h57a0305fa62d57cc@mail.gmail.com>
	<764B352CF55C514F816B4B14BD2450D803DBBF2C@bcs-mail04.internal.cacheflow.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Wed, 11 Nov 2009 16:26:16 -0600
Message-ID: <e06563880911111426t737e64f4o2660f4605b7c6b5f@mail.gmail.com>
Subject: Re: Re: bandwidth limiting Cassandra's replication and access control
To: cassandra-user@incubator.apache.org, cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

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?=A0 I agree.=A0 However, I believe=
 the
> more common case is to front the Cassandra service with an application
> layer, as you would expose a relational backend.=A0 For that kind of serv=
ice,
> the application should control the security.
>
>
>
> Basically, a user request to Cassandra is not stateful; any request shoul=
d
> be able to perform a transaction against any node in the cluster, using a=
n
> appropriate consistency model for the request.=A0 Requiring something lik=
e
> real time token synchronization across all nodes in a cluster seems outsi=
de
> of Cassandra=92s =A0eventual consistency model.
>
>
>
> Securing the data is intrinsically application-specific. =A0While I could=
 see
> adding a plugin that makes the CLI access point secured, I would still wa=
nt
> 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 writ=
ten
> several security layers on J2EE apps over the years and none of them have
> been the same.=A0 Besides that, I want the data layer to be highly effici=
ent
> and in my opinion, it isn=92t the work of the data service to impose secu=
rity.
>
>
>
> 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> wrot=
e:
>
> IMO, auth services should be left to the application layer that interface=
s
> to Cassandra and not built into Cassandra. =A0In the tutorial snippet inc=
luded
> below, the access being granted is at the codebase level, not the
> transaction level. =A0Since users of Cassandra will generally be fronted =
by a
> service layer, the java security manager isn=92t going to suffice. =A0Wha=
t 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.
> =A0However, if a user has physical access to the machine on which Cassand=
ra is
> installed, they could easily bypass that layer of security.
>
>
>
> What if Cassandra IS the application you're exposing? =A0Imagine a large
> company that creates one large internal Cassandra deployment, and has
> multiple departments it wants =A0to create separate keyspaces for. =A0You=
 can do
> that now, but there's nothing except a gentlemen's agreement to prevent o=
ne
> department from trashing another department's keyspace, and accidents do
> happen. You can front the service with some kind of application layer, bu=
t
> then you have another API to maintain, and you'll lose some performance t=
his
> way.
>
>
>
> -Brandon