cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Schiefelbein (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-2274) Restrict Cassandra cluster node joins to a list of named hosts
Date Mon, 07 Nov 2011 22:42:51 GMT

    [ 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

        

Mime
View raw message