I took a look at this too and also identified o.a.c.net.MessagingService as the best place to start adding receiver-side security. At the moment the authentication provided by o.a.c.auth.IAuthority and o.a.c.auth.IAuthenticator is client-side only, so no help in preventing nodes from processing requests from rogue or malicious nodes that have their authentication turned off (the default).
There are two approaches I identified for preventing unauthorised nodes from interacting with the cluster.
- The MessagingService defines a PROTOCOL_MAGIC value that it uses to determine if the node sending an incoming message is "sane". By changing this value from the default value it would effectively mean that only nodes running your own modified version of Cassandra would be able to communicate with each other, as all other nodes (including those using an official release) would treat your nodes as "insane" and refuse to communicate. This is a brutal way to achieve the goal, but it may be sufficient for some.
- Add some checking of messages that are received before the action they request is carried out. At the moment the receive() method in MessagingService does nothing to verify the authenticity or authority of an incoming message before queuing it for processing. However, the o.a.c.net.Message that is passed to the receive() method has a from field, which as David Allsopp points out contains the IP address of the receiving node. If the IP address is sufficient to ascertain the identity of the sender (for your use case) then this could form the basis of some validation, e.g. checking that the IP is in a list of allowed IPs (or range of IPs), either stored in a configuration file or, as has been suggested, in a cluster-wide shared column family (although I'm not quite sure how that would work in practice).
If IP address alone is not enough to identify a node (which is highly likely), then I think there is no choice but to extend the Message class to include extra identity and credentials information.
I'm not sure how feasible this is as I'm not familiar enough with Cassandra and its underlying protocols: if secured nodes were to use an extension of Message instead of Message itself then it's likely that unsecure nodes would not be able to process messages sent by secure nodes – but then perhaps that's the point.
When it comes to validating identity and credentials, it seems sensible to re-use existing PKI or similar mechanisms, through PAM integration to take advantage of system policies and AD or LDAP. The strategy used should be configurable and pluggable, just as the existing client-side security strategy is, and include the ability to turn off sender verification to allow the current status quo to continue in environments where that makes sense.
Unfortunately I don't have time to implement any of this right now, but really wish I did. This is an important aspect for us though so I may be able to have a go soon, if someone else doesn't beat me to it.