Page MenuHomePhabricator

secure Cassandra/RESTBase cluster
Closed, ResolvedPublic

Description

Implement a secure configuration for the RESTBase Cassandra cluster; This is a tracking ticket to organize the various existing issues (some in-progress), and any additional issues that may be needed.

Event Timeline

Eevans created this task.Mar 29 2015, 2:34 AM
Eevans raised the priority of this task from to Needs Triage.
Eevans updated the task description. (Show Details)
Eevans added a subscriber: Eevans.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 29 2015, 2:34 AM
fgiunchedi triaged this task as High priority.Apr 1 2015, 9:08 AM
fgiunchedi added a subscriber: fgiunchedi.
GWicke moved this task from Backlog to In progress on the RESTBase board.Apr 6 2015, 11:37 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJun 29 2015, 5:26 PM

@Eevans, is there anything actionable left to do here?

GWicke lowered the priority of this task from High to Low.Oct 12 2016, 5:45 PM
GWicke set Security to None.
GWicke added a project: Services (doing).

Tentatively moved to our done status. @Eevans, please close or move back to the backlog if there is more to be done here.

@Eevans, is there anything actionable left to do here?

@GWicke, the only remaining blocker is T92471: enable authenticated access to Cassandra JMX, which has languished for long enough that I think it's fair to ask whether or not it's important enough to worry about. So here goes...

There is no end to the damage you could do to the cluster using nodetool, (and the open RMI port it requires will allow remote execution of arbitrary code as user cassandra). However, firewall rules currently limit access to only the other machines in the Cassandra cluster. In other words, unauthenticated access is provided to anyone with access to the nodes of the cluster (provided the firewall remains intact), which is probably (roughly) what we want.

The question then: Is what we have good enough, or do we need the defense-in-depth that authenticated access would provide?

@dpatrick, @Joe, @fgiunchedi, @elukey Thoughts?

From a cost / benefit perspective, improving on the Firewall with a separate VLan might be more attractive than setting up JMX authentication. The focus on Kubernetes this quarter could improve our ability to set up VLans, which could bring this within reach in the foreseeable future. See T121240 for the general network segmentation discussion.

Joe added a comment.Oct 20 2016, 5:54 AM

From a cost / benefit perspective, improving on the Firewall with a separate VLan might be more attractive than setting up JMX authentication.

VLANs and firewalling are two distinct things, you mean adding hardware firewalls in the communications between the VLANs? Either way, it's a long shot from our current model.

The focus on Kubernetes this quarter could improve our ability to set up VLans,

I don't think this is accurate at all. Kubernetes will most probably use Calico as a networking solution, and that doesn't mean creating network segregation at all (which is what I think you want).

In terms of the concrete JMX protection question, the main proposals are:

  • Set up JMX authentication, with credentials stored accessible to shell (but not service) users on Cassandra nodes.
  • Add a firewall rule that only allows outgoing connections to JMX ports within the Cassandra cluster from a non-service group.

In terms of threats, differences seem to be:

  • Code execution on Cassandra nodes.
    • JMX authentication: User privileges need to be elevated to a non-service user / group to provide access to the credentials.
    • Firewall rule: User privileges need to be elevated to a non-service user / group to be able to connect to JMX port.
  • Other nodes circumventing the IP-based firewall by configuring a Cassandra cluster node IP.
    • JMX authentication: Passwords offer second line of defense.
    • Firewall rule: No defense.

So JMX auth would add a second line of defense for firewall circumvention, at the cost of some added complexity in tool wrappers and credential distribution.

Eevans closed this task as Resolved.Aug 26 2019, 10:01 PM
Eevans claimed this task.