[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142605#comment-13142605
]
David Allsopp commented on CASSANDRA-2274:
------------------------------------------
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?).
> 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
