[
https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141084#comment-13141084
]
Mark Allsopp edited comment on CASSANDRA-2274 at 11/1/11 11:35 AM:
-------------------------------------------------------------------
New to using cassandra at the moment, but this does cover an issue we are
seeing and I think the original comment seems valid for a number of cases.
I may be extending this a little too far, but is there a possibility of perhaps
going a little bit further than just a host list and extending it to a basic
remote node authentication. By default not trusting any new node that joins
and asks it to prove that it's a valid node.
Perhaps something as simple as just using a simple secret "password token" such
as a random character string that identifies the node as a member of a cluster
(and possibly even keyspace) and refusing access if it's not present would
start to kill two birds with a single stone.
Initially it could reply on an user keeping a properties files with the cluster
to token and keyspace to token mappings on each box. Kind of extending simple
auth to being simple remote auth.
Obviously there are still holes in what I'm suggesting from a security point of
view, but something that requires a new node to provide some degree of
likelihood that it really is who is says it is would be great.
was (Author: mallsopp):
New to using cassandra at the moment, but this does cover an issue we are
seeing and I think the original comment seems valid for a number of cases.
I may be extending this a little too far, but is there a possibility or perhaps
going a little bit further than just a host list and extending it to a basic
remote node authentication. By default not trusting any new node that joins
and asks it to prove that it's a valid node.
Perhaps something as simple as just using a simple secret "password token" such
as a random character string that identifies the node as a member of a cluster
(and possibly even keyspace) and refusing access if it's not present would
start to kill two birds with a single stone.
Initially it could reply on an user keeping a properties files with the cluster
to token and keyspace to token mappings on each box. Kind of extending simple
auth to being simple remote auth.
Obviously there are still holes in what I'm suggesting from a security point of
view, but something that requires a new node to provide some degree of
likelihood that it really is who is says it is would be great.
> 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
