You Write a Security Post and Then

One aspect of security is IP binding. The basic idea is that many middle tier engines allow you to specify which IP address, or subnet range, can access the engine. All other addresses will be spurned like a cheap lover.  There are some caveats I feel worth a quick mention.

When you are hosting your broker, rules engine, or database engine on the same machine as the code using it, you set the bind address to 127.0.0.1. A hacker needs to deliver their payload directly to your application server or node to compromise your engine/broker.

When you are hosting on a separate machine, but in the same LAN or private VPN, you can use a range of IP addresses to grant access to. This broadens the attack foot print, but still limits the number of machines an attacker can effectively deliver a payload to.  Seems like a win. However, in the world of automated DevOps delivery and multiple software environment deployment, you have to have a way to detect target environments you are installing your infrastructure packages to, as each environment may have a different IP range you want to lock it down to. So you may need a way to detect new VMs spun up for development that need the development IP binding range (or no IP binding) compared to your production environment range. This becomes even harder when you initially start co-locating your software at different data centers. Now you need an environment flag for production and other-production.

This task becomes a different confusion when using hosting services and containers like Docker. I have not worked on that myself, but be aware that you will need to have /etc/resolv.conf  play nicely with Docker's bridge interface.