[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141726#comment-13141726
]
David Allsopp commented on CASSANDRA-2274:
------------------------------------------
@Mark - There's a convenience/security trade-off there. Giving each node a
security token is easier and more flexible than configuring every node with a
list of all other nodes (it's a bit of a pain to have to update all existing
nodes each time you want to add a node). However, the security in this scenario
is to deal with a semi-insider attack. Getting hold of the token might be
easier for the attacker than having to somehow modify the access list on all
existing nodes.
However, what stops an attacker from modifying the access list on all existing
nodes? Only the login/password for those nodes. So in either case the weakest
link is the protection of a single password/token (maybe multiple passwords if
you have a different login for each node, but is that commonplace??).
Care would also be needed to make sure the shared secret isn't exposed over the
network, either as plaintext, or via replay of messages from existing nodes.
So whilst I think your proposal is appealing from the operational efficiency
point of view, it is probably harder to implement securely.
Trying to protect against an insider who might even have physical access to
your servers is a very tough game...
> 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
