cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Lowe (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2274) Restrict Cassandra cluster node joins to a list of named hosts
Date Mon, 07 Nov 2011 21:38:52 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145834#comment-13145834
] 

Richard Lowe commented on CASSANDRA-2274:
-----------------------------------------

I'd forgotten about the encryption options. Enabling encryption would certainly prevent against
rogue nodes entering the cluster (unless they had a valid key) but I can't see how it prevents
attacks from trusted nodes, i.e. through a malicious/erronous/compromised app or user action.
Such nodes would still be able to request an action that could (or should) require specific
privileges.

In our particular use case a drop of a keyspace without the authority to do so would be very
bad, whilst it sounds like the original reporter of this issue is concerned about the potential
for leaking data through unauthorized reads. I'd be surprised if there weren't other applications
for which deleting the database wouldn't cause a problem; at the very least it means downtime
to restore from the last set of snapshots.

Also, how would the use of encryption work in a multi-tenant environment? Would each tenant
have their own set of encryption keys? Does this sort of segregation of the cluster cause
problems in terms of gossip and thrift messaging?

The standard practice of rolling encryption keys might be difficult as well, requiring each
node to be stopped and restarted for updates to its keystore to take effect. This doesn't
satisfy the desire for the provision of security to be dynamically applied, as Andrew Scheifelbein
described previously.

If a key becomes compromised then a receiving node will still honor a sender's request because
it doesn't attempt to do any verification that the sender has the authority to performing
the action it is requesting be executed.

Encryption gets us quite a lot of the way, but it doesn't get us the whole way there in terms
of ensuring a node is only able to perform the actions it is authorized to do so upon the
cluster.
                
> 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