search

k8ssandra / k8ssandra-operator

The Kubernetes operator for K8ssandra
https://k8ssandra.io/
Apache License 2.0
176 stars 79 forks source link

Allow disabling Cassandra CQL client access from within the cluster when Stargate is enabled #581

Closed JeremiahDJordan closed 1 month ago

JeremiahDJordan commented 3 years ago

Is your feature request related to a problem? Please describe. When I have Stargate deployed in my cluster I would like to disable cql access to the cassandra nodes. I should be able to force all client access to be through Stargate.

Describe the solution you'd like A setting to disable access to the native protocol ports on cassandra nodes from client access from within the k8s cluster. Currently when Stargate is enabled that gets set to be the Ingress, but internal clients can still get to cassandra nodes. It would probably be useful to still leave native protocol running, but only bound to localhost, for debug access.

┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: K8OP-176

bradfordcp commented 2 years ago

Are clients required to use a Whitelist LBP to force limit which hosts (ie Stargate) to connect to?

Is there any sort of mechanism to adjust the metadata received by clients to avoid this scenario?

JeremiahDJordan commented 2 years ago

My understanding is that stargate only advertises other stargate nodes in the peers table.

bradfordcp commented 2 years ago

Thanks for the info. We need to validate if any other k8ssandra components are connecting over native protocol.

adutra commented 2 years ago

This may affect Reaper. If present, Reaper will use dc.GetDatacenterServiceName() as its contact point, effectively ignoring all Stargate nodes. Will this service still be reachable? If not, I guess Reaper would have to use the Stargate service instead.

jsanda commented 2 years ago

I believe Medusa makes CQL calls. This seems like an enhancement. Can we move this ticket to k8ssandra-operator?

jsanda commented 2 years ago

Poker planning estimates should be for work to be done in k8ssandra-operator.

jsanda commented 2 years ago

Please add your planning poker estimate with ZenHub @adutra

jsanda commented 2 years ago

Please add your planning poker estimate with ZenHub @burmanm

jsanda commented 2 years ago

Please add your planning poker estimate with ZenHub @adejanovski

adejanovski commented 2 years ago

@jsanda @adutra, how about creating a NetworkPolicy that only allows Reaper pods to access the Cassandra pods on the CQL port? That would give us some flexibility around this by still allowing both Reaper and Medusa to access the native port while preventing external access.

adutra commented 2 years ago

Network policies require a network plugin, and even if network plugins are installed by default on most cloud providers, we can't guarantee that there will always be such a plugin available. I'm not sure that this solution could be seen as a good default.

Taking a step back, I don't think it's a huge problem to leave the Cassandra pods accessible on 9042. As long as the user-facing applications are configured to hit the Stargate service, most if not all the CQL traffic would go through Stargate anyways. Having a few other clients such as Reaper connecting directly to Cassandra is not a big deal imo.

jsanda commented 2 years ago

Taking a step back, I don't think it's a huge problem to leave the Cassandra pods accessible on 9042

I agree and am inclined to consider this pretty low priority.