3

i just installed the datastax cluster of cassandra. i have a question regarding the security groups and how to limit access. currently, there are no security groups to the vnet and to all vms. so everyone can connect to the cluster. the problem starts when i try to set a security group on the subnet. this is because the http communication of the cassandra nodes is (i think) used with the public ip and not the internal ip. i get an error in the opscenter that the http connection is down.

the question is how can i restrict the access to the cluster (for a specific ip), but provide access to all the cassandra nodes to work.

Avi Cohen
  • 31
  • 1
  • Most of the time you do not want to provide direct access to cassandra. In production you should only allow access to the application layer. In development you could use an SSH tunnel. – grochmal Aug 05 '16 at 04:14
  • i agree. the problem is how to do it? there are conflicts between the inner cassandra communication and the restriction from outside – Avi Cohen Aug 05 '16 at 06:08
  • any update on this? – Timmerz Dec 02 '16 at 21:01

1 Answers1

1

Its good practice to exercise security when running inside any public cloud whether its Azure, GCE, or AWS etc. Enabling internode SSL is a very good idea because this will secure the internode gossip communications. Then you should also introduce internal authentication (at the very least) so you require a user/password to login to cqlsh. I would also recommend using client to node SSL, 1-way should be sufficient for most cases.

I'm not so sure about Azure but I know with AWS and GCE the instances will only have a local internally routed IP (usually in the 10.0.0.0/8 private range) and the public IP will be via NAT. You would normally use the public IP as the broadcast_address especially if you are running across different availability zones where the internal IP does not route. You may also be running a client application which might connect via the public ip so you'd want to set the broadcast_rpc_address as public too. Both of these are found in the cassandra.yaml. The listen_address and rpc_address are both IPs that the node will bind to so they have to be locally available (i.e. you cant bind a process to a IP thats not configured on an interface on the node).

Summary

  • Use internode SSL
  • Use client to node SSL
  • Use internal authentication at the very minimum (Ldap and Kerberos are also supported)

Useful docs

I highly recommend following the documentation here. Introducing security can be a bit tricky if you hit snags (whatever the application). I always start of making sure the cluster is running ok with no security in place then introduce one thing at a time, then test, verify and then introduce the next thing. Dont configure everything at once!

Firewall ports

Client to node SSL - note require_client_auth: true should be false for 1-way.

Node to node SSL

Preparing SSL certificates

Unified authentication (internal, LDAP, Kerberos etc)

Note when generating SSL keys and certs typically you'd just generate the one pair and use it across all the nodes when you have node to node SSL. Otherwise if you introduce a new node you'll have to import the new cert into all nodes, which isn't really scalable. In my experience working with organisations using large clusters this is how they manage things. Also client applications may well use just same key or a different one at least.

Further info / reading

2-way SSL is supported, but its not as common as 1-way. This is typically a bit more complex and switched on with the require_client_auth: true in the cassandra.yaml

If you're using OpsCenter for SSL, the docs (below) will cover things. Note that essentially its in two places:

  • SSL between opscenter and the agents and the cluster (same as client to node SSL above)
  • SSL between OpsCenter and the Agents

OpsCenter SSL configuration

I hope this helps you towards achieving what you need to!

markc
  • 2,129
  • 16
  • 27