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 7036611257 for ; Sat, 5 Apr 2014 06:30:34 +0000 (UTC) Received: (qmail 12863 invoked by uid 500); 5 Apr 2014 06:30:31 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 12371 invoked by uid 500); 5 Apr 2014 06:30:30 -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 12362 invoked by uid 99); 5 Apr 2014 06:30:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2014 06:30:28 +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 (athena.apache.org: domain of comptechgeeky@gmail.com designates 74.125.82.43 as permitted sender) Received: from [74.125.82.43] (HELO mail-wg0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2014 06:30:24 +0000 Received: by mail-wg0-f43.google.com with SMTP id x13so4425811wgg.14 for ; Fri, 04 Apr 2014 23:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FzI8JTJPrn6NFZQmKbXSF1++8DMzIcDRbDm+Klma64E=; b=mw+yTg7ixZEUXaKg+m6uPu1DjdLDRUsOmAi0oWuKIOBLV6ou75rjCmE/x13plMmsiN tRQYfh7HdxLPgzRWnf49uudDdPhM74u7/0YZZwRXZ7K+PdNYiPXTv7Y1OLBWgb+bhAXV ZmEjCPXtsTgaXMU3XYxrPkX0UsyLyg+lgFuY2rLkcgtE40pi8MQNkovovyBy2DuTCQ+2 N3/Wo7UG6rMmhm4Px3JVB7Yla3MgBJpYBmXxvtypSvmUYuiQA5OUIAd/Rvp/UNbSUxsm 98cRyEu93zfsemkkHFnbv1vJPT4d99ObjNyOcqdq3cm2pLZUC55UlSSW6yGN3oUR2GaO cc5A== X-Received: by 10.194.92.81 with SMTP id ck17mr4746995wjb.14.1396679402992; Fri, 04 Apr 2014 23:30:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.208.200 with HTTP; Fri, 4 Apr 2014 23:29:42 -0700 (PDT) In-Reply-To: References: From: Check Peck Date: Fri, 4 Apr 2014 23:29:42 -0700 Message-ID: Subject: Re: Securing Cassandra database To: user Content-Type: multipart/alternative; boundary=047d7bfceb6aae36e004f645c331 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bfceb6aae36e004f645c331 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > Hi, > > If you want to just secure OpsCenter itself take a look here: > http://www.datastax.com/documentation/opscenter/4.1/opsc/configure/opscAssigningAccessRoles_t.html > > > 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/.conf > Binary installs: /conf/clusters/.conf > Windows installs: Program Files (x86)\DataStax > Community\opscenter\conf\clusters\.conf > > Open the file and update the username and password values under the > [cassandra] section: > > [cassandra] > username = > seed_hosts = > api_port = > password = > > 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 wrote: > >> Hi All, >> >> We would like to secure our Cassandra database. We don't 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? >> >> >> >> > > --047d7bfceb6aae36e004f645c331 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Mark. But what about Cassandra database? = I don't want anybody to read and write into our Cassandra database thro= ugh any API only just our team should be able to do that.

We a= re 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 pos= sible 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 just secure OpsCenter itself take a look here: http://www.datastax.com/doc= umentation/opscenter/4.1/opsc/configure/opscAssigningAccessRoles_t.html=


If you want to enable internal authentic= ation and still allow OpsCenter access, you can create an OpsCenter user an= d once you have auth turned within the cluster update the cluster config wi= th 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 in= stalls: /etc/opscenter/clusters/<cluster_specific>.conf
Binary installs: <install_location>/conf/clusters/<cluster_specifi= c>.conf
Windows installs: Program Files (x86)\DataStax Communi= ty\opscenter\conf\clusters\<cluster_specific>.conf

Open the file and update the username and password values under = the [cassandra] section:

[cassandra]
use= rname =3D 
seed_hosts =3D 
api_port =3D
password =3D 

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


Mark

--047d7bfceb6aae36e004f645c331--