Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 7 Nov 2011 22:42:51 +0000 (UTC)
From: "Andrew Schiefelbein (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1277835397.8565.1320705771584.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2070665552.14937.1299266016953.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (CASSANDRA-2274) Restrict Cassandra
 cluster node joins to a list of named hosts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145900#comment-13145900 ] 

Andrew Schiefelbein edited comment on CASSANDRA-2274 at 11/7/11 10:42 PM:
--------------------------------------------------------------------------

{quote}Good point about storing the settings in the Cassandra storage itself, though it looks from https://issues.apache.org/jira/browse/CASSANDRA-3319 as though it needs to be a non-system keyspace . It feels wrong for it to be a 'normal' keyspace though, as it would need to have a predetermined name and schema in order for various parts of the server code to use if when authenticating, and it would have the same visibility and access as normal data keyspaces (surely it should require greater privileges, as for schema modifications and other 'dangerous' operations?).{quote}

If you go according to the OpenLDAP model there is a separate LDAP database that contains the settings that is used by the underlying system, it has a separate login than the normal database that it's serving and never the two shall meet.  To translate that to Cassandra there would have to be a separate keyspace or maybe in this case possibly a "database" that is serving the cluster wide options.  I haven't really thought through the different permutations on this, but I would hope it is achievable.

{quote}
It seems to me, if you really want to do this properly, you should enable the existing encryption options.
{quote}

I agree that encryption is part of the solution, not the solution for this I'm sorry to say, unless you choose to become your own CA or have something that checks an embedded thing in, oh say, the OU level of the certificate (encrypted has of course, otherwise it's clear text), it is fairly easy to get a signed certificate that will pass through the normal SSL handshake without question, it also doesn't solve the problem of we only want a select group of nodes in.  If there is something like Apache HTTPD's SSLRequire (http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslrequire) that allows for some form of regular expression that checks a number of things that may actually be pretty close to what I was suggesting, but you would still need to maintain the list of stuff you want checked cluster wide.  Only those nodes you want to talk to should be allowed in, all others should be told to go away or you will taunt them a second time.

                
      was (Author: as3525):
    {quote}Good point about storing the settings in the Cassandra storage itself, though it looks from https://issues.apache.org/jira/browse/CASSANDRA-3319 as though it needs to be a non-system keyspace . It feels wrong for it to be a 'normal' keyspace though, as it would need to have a predetermined name and schema in order for various parts of the server code to use if when authenticating, and it would have the same visibility and access as normal data keyspaces (surely it should require greater privileges, as for schema modifications and other 'dangerous' operations?).{quote}

If you go according to the OpenLDAP model there is a separate LDAP database that contains the settings that is used by the underlying system, it has a separate login than the normal database that it's serving and the two shall meet.  To translate that to Cassandra there would have to be a separate keyspace or maybe in this case possibly a "database" that is serving the cluster wide options.  I haven't really thought through the different permutations on this, but I would hope it is achievable.

{quote}
It seems to me, if you really want to do this properly, you should enable the existing encryption options.
{quote}

I agree that encryption is part of the solution, not the solution for this I'm sorry to say, unless you choose to become your own CA or have something that checks an embedded thing in, oh say, the OU level of the certificate (encrypted has of course, otherwise it's clear text), it is fairly easy to get a signed certificate that will pass through the normal SSL handshake without question, it also doesn't solve the problem of we only want a select group of nodes in.  If there is something like Apache HTTPD's SSLRequire (http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslrequire) that allows for some form of regular expression that checks a number of things that may actually be pretty close to what I was suggesting, but you would still need to maintain the list of stuff you want checked cluster wide.  Only those nodes you want to talk to should be allowed in, all others should be told to go away or you will taunt them a second time.

                  
> Restrict Cassandra cluster node joins to a list of named hosts
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-2274
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2274
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7.2
>         Environment: All
>            Reporter: Andrew Schiefelbein
>
> Because firewalls and employees are not infallible it would be nice to restrict the ability of any node to join a cluster to a list of named hosts in the configuration so that someone would be unable to start a node and replicate all the data locally.  I understand that in order to do this the person must know the seed servers and the cluster name and to extract the data they will need a userid and password but another level of security would be to force them to execute any brute force attack from a locked down server instead of replicating all the data locally.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira