I want to use rabbitmq in a project, some clients have to comunicate with the rabbitmq server over internet
What is the best way to expose rabbitmq on the Internet ?
should i use a http gateway or directly expose the rabbitmq port ?
Guillaume.
Yes, you can, it is what https://www.cloudamqp.com/ does.
You need to implement the same security policies you'd use for a web site.
For example, put a load-balancer in front of your rabbitmq cluster, use the SSL connections, you could also configure your firewall to accept the connections only from specific ip addresses etc etc..
Related
Can we use PLAINTEXT and SSL in the Production environment, especially when brokers are within the same sub net and they are protected by Firewall?
I want to use SSL only for external connections like Kafka Connect.
Yes, you can list as many listeners as you have ports available in the listeners property on the brokers.
For instance, you can define PLAINTEXT_SASL between the brokers for replication, and allow for PLAINTEXT/PLAINTEXT_SASL & SSL/SASL_SSL for external traffic
Is kafka suitable for Internet-use?
More precisely, what I want is to expose kafka topics as "public interface", then external consumers (or producers) can connect to it. Is it possible?
I hear there are problems if I want to use the cluster in both internal and external networks, because it is then hard to configure advertised.host.name. Is that true?
And do I have to expose zookeeper as well? I think the new consumer/producer api no longer need that.
Kafka's wire protocol is TCP-based and works fine over the public internet. In the latest versions of Kafka you can configure multiple interfaces for both internal and external traffic. Examples of Kafka over the internet in production include several Kafka-as-a-Service offerings from Heroku, IBM MessageHub, and Confluent Cloud.
You do not need to expose zookeeper if the Kafka clients use the new consumer API.
You may also choose to expose a REST Proxy such as the open source Confluent REST Proxy as a more client firewall friendly interface since it runs over HTTP(S) and will not be blocked by most corporate or personal firewalls.
I would personally not expose the Kafka server directly to clients via TCP for these reasons, only to name a few:
If a bad client opens too many connections this may affect the stability of the Kafka platform and may affects other clients too
Too many open files on the Kafka server, HW/SW settings and OS tuning is needed to limit uncontrolled clients
If you need to add a Kafka server to increase scalability, you may need to go through a lot of low level configuration (firewall, IPs visibility, certificates, etc.) on both client and server side. Other product address these problems using gateways or proxies: Coherence uses extend proxy clients, tibco EMS uses routed destinations, other SW (many JMS servers) use Store&Forward mechanisms, etc.
Maintenance of the Kafka nodes, in case of clients attached to the Kafka servers, will have to consider also the needs of clients and the SLA (service level aggreement) that have been defined with the client (ex. 24*7*365)
If you use Kafka also as a back end service, a multi layered architecture should be taken into consideration: FE gateways and BE services, etc.
Other considerations require to understand what exacly you consider to be an external (over the internet) consumer/producer in your system. Is it a component of your system that needs to access the Kafka servers? Are they internal or external to your organization, etc.
...
Naturally all these considerations can be correctly addressed also using a TCP direct connection to the Kafka servers, but I would personally use a different solution.
HTTP proxies
Or at least I would use a dedicated FE Kafka server (or couple of servers for HA) dedicated for each client that forward the messages to the main Kafka group of servers
It is possible to expose Kafka over the internet (in fact, that's how managed Kafka providers such as Aiven and Instaclustr make their money) but you have to ensure that it is adequately secured. At minimum:
ZooKeeper nodes should reside in a private subnet and not be routable from outside. ZK's security is inadequate and, at any rate, it is no longer required to bootstrap Kafka clients with ZK address(es).
Limit access to the brokers at the network level. If all your clients connect from a trusted network, then set appropriate firewall rules. If in AWS, use VPC peering or Direct Connect if you are connecting cloud-to-cloud or cloud-to-ground. If most of your clients are on a trusted network but a relative minority are not, force the latter to go via a VPN tunnel. Finally, if you want to allow connectivity from arbitrary locations, you'll just have to allow * on port 9092 (or whichever port you configure the brokers to listen on); just make sure that the other ports are closed.
Enable TLS (SSL) for client-broker connections. This is easily configured with a self-signed CA. Depending on how you expose your listeners, you may need to disable SSL hostname verification on the client. (The certificate chain of trust breaks if the advertised host names don't match the certificate's common name.) The clients will need the CA certificate installed. (Same CA that signed the brokers' certs.)
Optionally, you may enable mutual TLS authentication; however, this is logistically more taxing, as it requires each client to have its own private key that is signed by a CA trusted by the broker.
Use SASL to authenticate the client to the broker and create individual users for each application and each person that is expected to access the cluster.
Issue minimally-sufficient cluster- and topic-level access privileges in the ACLs for each user, following the Principle of Least Privilege (PoLP).
One other thing to bear in mind: Not all tooling supports SASL/SSL connectivity and some tools actually require a connection to ZooKeeper nodes (which will not be reachable in the above setup). Make sure any tooling you rely on uses the 'new' style of connectivity directly to the Kafka brokers and does not require a Zookeeper connection.
Beyond configuring client TLS, brokers have to have public IPs which we try to avoid. Normally for other services we hide everything behind load balancers. Would this be possible with kafka?
I'm not sure the Confluent REST proxy hosted on a public server is a real option when you need the high performance batching of the java producer client.
I have a lot of different machines in multiple geographical locations. I need to command them from my backend and get data from them. I was thinking about connecting them all to a rabbitmq amqps connection to enable the bi-directionnel communication of my machines.
Is it a good approach? Is rabbitmq secure enough to do that?
Is it a good approach?
yes! RabbitMQ makes it very easy to communicate between systems, through the internet. As long as each machine / process can access the same RabbitMQ (server / cluster), you should be ok.
Is rabbitmq secure enough to do that?
Yes, as long as you follow standard security practices like any application that you expose to the internet.
Use firewalls, use SSL, set secure usernames and passwords with limited permissions, etc.
On the Internet, if you need fast,
secure server-to-server communication,
and you can specify which firewall
ports are open, NetTcpBinding can
prove very valuable.
a) Is text implying that with some other connection protocols, such as HTTP, we don't need to check for open firewall ports?
b) Why would NetTcpBinding only be useful for server-to-server communications, but not for client-to-server communications?
thank you
a) When you deploy to an enterprise, you usually don't have control over their external firewall. The setup of their firewall is made by network administrators following an enterprise wide policy. External firewalls almost always allow outgoing HTTP requests (otherwise you couldn't browse the web). Some corporate firewalls block outgoing TCP requests, which means you cannot use netTcpBinding. As an example, see this question for somebody trying to deal with that issue. If you KNOW that the firewall of every one of your customers will allow outgoing TCP, then NetTcpBinding is an appropriate choice.
b) Who says NetTcpBinding is only useful for server-to-server communications? You can deploy a client-server application into an enterprise, and providing the clients and the servers are all within the intranet, then NetTcpBinding is an appropriate choice of binding.
We have created a WCF using net.tcp with an anticipation that the service can work in a firewall that would accept only HTTP port. The client behind firewall can also access it.
Do we need to host the service on a static, public IP so that any client from any network can conect to it?
Ideally, we would like to host the service on a node behind a firewall (say on 192.168.0.199) so that a client on some other network could connect to it.
Please suggest.
Well, either you need to make the service publicly visible somehow - using a public IP, or by routing a publicly visible IP on your corporate firewall to your internal server. But yes - it needs to be publicly visible one way or another.
The other option would be to connect it to the Windows Azure Service Bus - in that case, you could keep it behind the firewall, and just establish a publicly visible IP "in the cloud" that will then route the traffic to your web server.
Marc
I may be off on this but WCF client should have no issues communicating with a WCF server behind a firewall. Even application - level firewalls are OK in this scenario, as long as you configure them to not inspect past layer 4. Do not authenticate or do anything with your traffic at the firewall - simply NAT it to an inside IP address and you should be ok.
Couple of notes: transport security might be a little better to this observer but both transport and message level security in WCF should work without problems through firewalls. If you need message streaming though, then you are stuck with transport level security.
If your firewall (or one of your firewalls) happens to be Microsoft ISA or TMG type device, you may find this helpful: http://www.run-corp.com/how-to-configure-wcf-application-on-microsoft-isa-tmg-firewall/.