Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce security to prevent churn and connection exhausting #16

Open
stefano-vardanega opened this issue Oct 20, 2020 · 13 comments
Open

Comments

@stefano-vardanega
Copy link

HAProxy, load balancer, socket tuning ?

@gerhard
Copy link
Contributor

gerhard commented Oct 26, 2020

This is a good one! 2 questions:

  1. Can we agree on K8S as the baseline?
    Ingress makes this much easier to capture, follow along & keep it relevant for longer-term.

  2. Any specific K8S that you would consider using for RabbitMQ?
    Apparently there are 168+ to choose from 🤯
    We have covered GKE & DKE already, but LKE & SKE are equally easy.

@stefano-vardanega
Copy link
Author

Yeah, great. Go for k8s.
I personally use Digital Ocean k8s to publish an MQTTS on 8883, but without ingress. So I'm greatly interested in DO ;).

@gerhard
Copy link
Contributor

gerhard commented Oct 26, 2020

Perfect, Digital Ocean Kubernetes Engine it is.

I feel that this Twitter thread with @evoxmusic is also related. Do those problems resonate with you @stefano-vardanega?

@stefano-vardanega
Copy link
Author

Good 👍
That's exactly my current concerns!

@gerhard
Copy link
Contributor

gerhard commented Oct 26, 2020

Feel free to share your thoughts on the above @Gsantomaggio 😉

@Gsantomaggio
Copy link
Member

Gsantomaggio commented Oct 26, 2020

Oh ! that's an interesting topic.

There is also Istio Traffic Management, here an example with RabbitMQ.

The same with HA-Proxy, we can also play with the TCP Backlog queues and TIME_WAIT.

@gerhard
Copy link
Contributor

gerhard commented Oct 26, 2020

Istio will be a good one to start with, but I expect performance to become an issue soon. Let's measure and see if HAproxy is as good as it claims.

@Gsantomaggio
Copy link
Member

Just a thought ...
Would be interesting to try to implement an XDP_DROP

It would drop / avoid ddos attach or not valid connections

interesting post to read

@gerhard
Copy link
Contributor

gerhard commented Oct 27, 2020

That sounds like a great R&D project, I'm thinking longer-term. I bet @essen would be interested in eBPF too.

Short-term, we should definitely lean on Envoy/Istio & maybe HAproxy as a first step, then iterate towards eBPF.

@Gsantomaggio
Copy link
Member

Can we agree on K8S as the baseline?
Ingress makes this much easier to capture, follow along & keep it relevant for longer-term.

I'd like to add that the standard k8s ingress supports only HTTP(s) so it is ok for management UI and not for the amqp.

It should be possible to use the SNI TLS extension to manage the traffic.

HAProxy, Traefik etc support TLS with SNI and also the strict sni policy

Here an example of amqps with SNI:
Screenshot 2020-11-09 at 22 10 56

This is still work in progress btw!

@gerhard
Copy link
Contributor

gerhard commented Nov 9, 2020

Looking great Gabriele, this will be a great TGIR 👍🏻

Would you find it useful to fork and start preparing the setup? I would recommend starting from the S01E07 branch (soon to be merged & deleted) so that we can hit the ground running 😉

@Gsantomaggio
Copy link
Member

Ok, I did some test with Traefik using SNI and strict sni configuration, using a configuration like this:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: rabbitmq-big-ingress
spec:
  routes:
  - match: HostSNI(`rabbit.bigcluster`)
    services:
    - name: big-cluster
      port: 5671
  tls:
     passthrough: true
     secretName: tls-big-secret
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: rabbitmq-ingress
spec:
  routes:
  - match: HostSNI(`rabbit.cluster`)
    services:
    - name: cluster
      port: 5671
  tls:
     passthrough: true
     secretName: tls-secret

we can use the same IP address and handle different rabbitmq clusters.

We have to finish it and test it, for the moment the configuration it seems to work correctly

@gerhard
Copy link
Contributor

gerhard commented Dec 31, 2020

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants