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.
Related
Our web and mobile application suite is used by some government agencies requiring strong security. We're providing XMPP-based chat. We used Openfire as XMPP server, but it turned out Openfire clustering (provided by Hazelcast plugin) does not allow Openfire nodes to communicate over SSL. We're not allowed to use node-to-node communications without SSL.
So, we're currently looking at Ejabberd XMPP server as a (more scalable) alternative to Openfire. But it looks like Ejabberd cluster nodes also communicate without SSL. Is it possible to set up Ejabberd cluster with nodes using SSL to talk to each other?
There is two ways to enable clustering over TLS with ejabberd:
You can set Erlang distribution over TLS: http://erlang.org/doc/apps/ssl/ssl_distribution.html
You can use VPN to protect your cluster.
Typically, the second solution is best for performance, as you offload the SSL processing from your cluster to a lower level layer. Clustering in ejabberd is not intended to be set over the internet, as you need low latency between your node for optimal operation.
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.
A Zookeeper architecture question for you ZK Gurus:
I use zookeeper to manage messaging to a cloud of worker machines. Currently the application servers that control the messages and the workers are in the same infrastructure (network). I'm considering allowing clients to communicate with these servers outside of the network from arbitrary locations. I've read about Zookeepers ACL and Authentication Capabilities but I notice that digest sends the passwords in cleartext. I'd be concerned about securing the socket connection and protecting against outside attacks. I dont see anything online telling me that this IS/IS NOT something that can/should be done with Zookeeper.
Is this a common architecture with Zookeeper and are there any suggestions?
Am I barking up the wrong tree for this type of work?
if you do not have a secured network (VPN), this in not something you should do for exactly the reason pointed out. you can mitigate the problem quite a bit using the kerberos plug in, which will secure the authentication and authorization, but you still will not get confidentiality (encryption). what you really need is SSL. things are setup now so that SSL support could be implemented, but code still needs to be written :)
Is you're building a distributed architecture with various services, is it acceptable to have those services communicate via ssh port forwarding, so that to a client a service looks like it's being served on a local port?
The only person who can answer "is it acceptable" is you, or your client.
Is it wise? Probably not, because SSL with certificates at both ends will deliver the same capability with a much less troublesome intermediate layer, but that is an engineering decision you have to make.
We're using a duplex contract for one feature in our yet to be released enterprise level LOB application that utilizes a thick client built with WPF and a server built with WCF.
During development so far we've been using the net.tcp binding for best performance. Now that deployment is coming up and issues such as internet access through a web proxy come to light, net.tcp isn't suitable anymore.
I've started using wsHttp and wsDualHttp but have realised in the meantime that duplex connections through a web proxy (and with NAT traversal) isn't really possible.
Now I'm thinking: why can't I set up a tcp tunnel (using proprietry software that supports web proxies, using HTTP CONNECT) and get the best of both worlds, proxy support, speed and security?
It would seem this is a common requirement.
Your options are not expansive. Microsoft's Service Bus is probably your best bet, if it works for your needs. The other options are:
VPN: Pretty self-explanatory.
SSH: SSH has tunneling functionality built-in. If you only have a small number of connections, you might be able to use an off-the-shelf SSH client and server, but with a larger number of connections it's hard to ensure that they all stay connected reliably. Several companies make SSH components you might be able to build upon (they didn't work for our needs), but they are more oriented toward the remote-execution use of SSH than tunneling.
A DIY TCP tunnel, which is a big job. Not impossible, but a big job. And will require a tremendous amount of testing to make sure you've got it right.
As far as running WCF over a tunneled connection, if you go that route, you won't have any problems. All the bindings and features work-- callbacks, reliability, message security, transport security, transactions, all work just fine.