Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0057611C5B for ; Sat, 5 Apr 2014 18:38:10 +0000 (UTC) Received: (qmail 75503 invoked by uid 500); 5 Apr 2014 18:38:06 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 75143 invoked by uid 500); 5 Apr 2014 18:38:05 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 75135 invoked by uid 99); 5 Apr 2014 18:38:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2014 18:38:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jonathan.haddad@gmail.com designates 209.85.220.45 as permitted sender) Received: from [209.85.220.45] (HELO mail-pa0-f45.google.com) (209.85.220.45) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2014 18:37:58 +0000 Received: by mail-pa0-f45.google.com with SMTP id kl14so4906718pab.18 for ; Sat, 05 Apr 2014 11:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:message-id:mime-version:subject:date :references:to:in-reply-to; bh=6Nd+tKsjWbePkzrMzuI0c4G8Ji0sB4R7MShC68wBZU4=; b=p/WCu0PTuwja4R4WB1yw9m79iYUfqSmJlUvwSsLd20JX1s7KBzhDigLajQpRPg5e9u 3sMILqss+Fe26M3PT+nlTiY+7VHduHhL339BGCjJKH59Ke+m5jWniHVfx0ezdbupK8pl +mgP+LP6K/YahETPaKO+TDciaFTv/cOtfTUVNDiBh2xtTMnM5aJZSoaKUr7KQCCrt+L2 MePNb8n5Zz2XrRtWQwa0n5BbKdZvMd9eqlEarBWvSc9sH6VuYymP3RaJoBeLsFHz+4Qm aBqtqCzOmIx/1BFClzVuqvp29Xi+4gG35iElaX9krxHNjo4Bb9MwjvwIfYe5GRsVtyB1 LBrg== X-Received: by 10.68.245.162 with SMTP id xp2mr21813751pbc.69.1396723055378; Sat, 05 Apr 2014 11:37:35 -0700 (PDT) Received: from new-host-6.home (pool-173-60-205-186.lsanca.fios.verizon.net. [173.60.205.186]) by mx.google.com with ESMTPSA id fg12sm59370804pac.28.2014.04.05.11.37.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 11:37:34 -0700 (PDT) Sender: Jon Haddad From: Jon Haddad Content-Type: multipart/alternative; boundary="Apple-Mail=_23F7C462-F4FC-4E2F-8EE6-B3E8A7922712" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Securing Cassandra database Date: Sat, 5 Apr 2014 11:37:32 -0700 References: To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1874) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_23F7C462-F4FC-4E2F-8EE6-B3E8A7922712 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This isn=92t Cassandra specific, but this is why I hate including db = configuration with the main codebase instead of making it the = responsibility of ops. This case you described shouldn=92t even be = possible. The production db configs should be provided by the team = maintaining the production environment, and not even accessible outside = it. On Apr 5, 2014, at 6:45 AM, Robert Wille wrote: > Password protection doesn=92t protect against an engineer accidentally = running test cases using the live config file instead of the test config = file. To protect against that, our RDBMS system will only accept = connections from certain IP addresses. Is there an equivalent thing in = Cassandra, or should we configure firewall software for that? >=20 > From: Mark Reddy > Reply-To: > Date: Saturday, April 5, 2014 at 12:38 AM > To: > Subject: Re: Securing Cassandra database >=20 > Ok so you want to enable auth on Cassandra itself. You will want to = look into the authentication and authorisation functionality then.=20 >=20 > Here is a quick overview: = http://www.datastax.com/dev/blog/a-quick-tour-of-internal-authentication-a= nd-authorization-security-in-datastax-enterprise-and-apache-cassandra >=20 > This section of the docs should give you the technical details needed = to move forward on this: = http://www.datastax.com/documentation/cassandra/1.2/cassandra/security/sec= urityTOC.html >=20 >=20 > Mark=20 >=20 >=20 > On Sat, Apr 5, 2014 at 7:31 AM, Check Peck = wrote: >> Just to add, nobody should be able to read and write into our = Cassandra database through any API or any CQL client as well only our = team should be able to do that. >>=20 >>=20 >> On Fri, Apr 4, 2014 at 11:29 PM, Check Peck = wrote: >>> Thanks Mark. But what about Cassandra database? I don't want anybody = to read and write into our Cassandra database through any API only just = our team should be able to do that. >>>=20 >>> We are using CQL based tables so data doesn't get shown on the = OPSCENTER. >>>=20 >>> In our case, we would like to secure database itself. Is this = possible to do as well anyhow? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, Apr 4, 2014 at 11:24 PM, Mark Reddy = wrote: >>>> Hi,=20 >>>>=20 >>>> If you want to just secure OpsCenter itself take a look here: = http://www.datastax.com/documentation/opscenter/4.1/opsc/configure/opscAss= igningAccessRoles_t.html >>>>=20 >>>>=20 >>>> If you want to enable internal authentication and still allow = OpsCenter access, you can create an OpsCenter user and once you have = auth turned within the cluster update the cluster config with the user = name and password for the OpsCenter user. >>>>=20 >>>> Depending on your installation type you will find the cluster = config in one of the following locations: >>>> Packaged installs: /etc/opscenter/clusters/.conf >>>> Binary installs: = /conf/clusters/.conf >>>> Windows installs: Program Files (x86)\DataStax = Community\opscenter\conf\clusters\.conf >>>>=20 >>>> Open the file and update the username and password values under the = [cassandra] section: >>>>=20 >>>> [cassandra] >>>> username =3D=20 >>>> seed_hosts =3D=20 >>>> api_port =3D >>>> password =3D=20 >>>>=20 >>>> After changing properties in this file, restart OpsCenter for the = changes to take effect. >>>>=20 >>>>=20 >>>> Mark >>>>=20 >>>>=20 >>>> On Sat, Apr 5, 2014 at 6:54 AM, Check Peck = wrote: >>>>> Hi All, >>>>>=20 >>>>> We would like to secure our Cassandra database. We don=92t want = anybody to read/write on our Cassandra database leaving our team members = only. >>>>> =20 >>>>> We are using Cassandra 1.2.9 in Production and we have 36 node = Cassandra cluster. 12 in each colo as we have three datacenters. >>>>>=20 >>>>> But we would like to have OPSCENTER working as it is working = currently. >>>>> =20 >>>>> Is this possible to do anyhow? Is there any settings in yaml file = which we can enforce? >>>>>=20 >>>>> =20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_23F7C462-F4FC-4E2F-8EE6-B3E8A7922712 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
This isn=92t Cassandra specific, but this is = why I hate including db configuration with the main codebase instead of = making it the responsibility of ops.  This case you described = shouldn=92t even be possible.  The production db configs should be = provided by the team maintaining the production environment, and not = even accessible outside it.

On Apr 5, 2014, at 6:45 = AM, Robert Wille <rwille@fold3.com> = wrote:

Password protection doesn=92t = protect against an engineer accidentally running test cases using the = live config file instead of the test config file. To protect against = that, our RDBMS system will only accept connections from certain IP = addresses. Is there an equivalent thing in Cassandra, or should we = configure firewall software for that?

From: Mark = Reddy <mark.reddy@boxever.com>
<= span style=3D"font-weight:bold">Reply-To: <user@cassandra.apache.org>= ;
Date: Saturday, April 5, = 2014 at 12:38 AM
To: <user@cassandra.apache.org>= ;
Subject: Re: Securing = Cassandra database

Ok so you want to enable auth on = Cassandra itself. You will want to look into the authentication and = authorisation functionality then. 



On Sat, Apr 5, 2014 at 7:31 AM, Check Peck <comptechgeeky@gmail.com> = wrote:
Just to add, nobody should be able to read and write into = our Cassandra database through any API or any CQL client as well = only our team should be able to do that.


On Fri, Apr 4, 2014 at 11:29 PM, Check Peck <comptechgeeky@gmail.com> = wrote:
Thanks Mark. But what about Cassandra database? I = don't want anybody to read and write into our Cassandra database through = any API only just our team should be able to do that.

We = are using CQL based tables so data doesn't get shown on the = OPSCENTER.

In our case, we would like to secure database = itself. Is this possible to do as well anyhow?





On Fri, Apr 4, = 2014 at 11:24 PM, Mark Reddy <mark.reddy@boxever.com> = wrote:
Hi, 


If you want to enable internal authentication and still = allow OpsCenter access, you can create an OpsCenter user and once you = have auth turned within the cluster update the cluster config with the = user name and password for the OpsCenter = user.

Depending on your installation type = you will find the cluster config in one of the following = locations:
Packaged installs: = /etc/opscenter/clusters/<cluster_specific>.conf
Binary installs: = <install_location>/conf/clusters/<cluster_specific>.conf
=
Windows installs: Program Files (x86)\DataStax = Community\opscenter\conf\clusters\<cluster_specific>.conf
=
Open the file and update the username and password values = under the [cassandra] = section:

[cassandra]
username = =3D 
seed_hosts =3D 
api_port = =3D
password =3D 

After changing = properties in this file, restart OpsCenter for the changes to take = effect.


Mark


On Sat, Apr 5, 2014 at 6:54 AM, Check Peck <comptechgeeky@gmail.com> = wrote:
Hi = All,

We would like to secure our = Cassandra database. We don=92t want anybody to read/write on our Cassandra database leaving our team = members only.
 
We are = using Cassandra 1.2.9 in Production and we have 36 node Cassandra = cluster. 12 in each colo as we have three datacenters.

But we would like = to have OPSCENTER working as it is working currently.
 
Is = this possible to do anyhow? Is there any settings in yaml file which we = can enforce?

 




= --Apple-Mail=_23F7C462-F4FC-4E2F-8EE6-B3E8A7922712--