This isn’t 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’t 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 <rwi...@fold3.com> wrote:

> Password protection doesn’t 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.re...@boxever.com>
> 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. 
> 
> Here is a quick overview: 
> http://www.datastax.com/dev/blog/a-quick-tour-of-internal-authentication-and-authorization-security-in-datastax-enterprise-and-apache-cassandra
> 
> 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/securityTOC.html
> 
> 
> Mark 
> 
> 
> On Sat, Apr 5, 2014 at 7:31 AM, Check Peck <comptechge...@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 <comptechge...@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.re...@boxever.com> 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/<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 = 
>>>> 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 <comptechge...@gmail.com> 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?
>>>>> 
>>>>>  
>>>> 
>>> 
>> 
> 

Reply via email to