[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145900#comment-13145900
]
Andrew Schiefelbein commented on CASSANDRA-2274:
------------------------------------------------
{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 database that it's serving and the two shall meet. To
translate that to Cassandra there would have to be a separate keyspace or 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
