Keep broker configuration in version control and add a check that fails the pull request when a change weakens a known setting: Redis bound to all interfaces without credentials, Kafka listeners on PLAINTEXT, RabbitMQ default accounts opened up, or an SQS policy with a wildcard principal. Review the rest by hand with a short checklist.
Why pull requests are the right place
Most exposed brokers were not hacked through a clever bug. Someone changed a setting during an outage, or copied a template, and nobody noticed. Redis documentation notes that many instances end up on public addresses because administrators ignored protection or disabled it. A pull request is the one moment where a change is visible, has an author, and can still be stopped.
What to check
| System | Change to flag | Why |
|---|---|---|
| Redis | A bind setting that opens all interfaces, protected mode turned off, a default user with no password | Redis is built for trusted environments, and these remove its safeguards |
| Redis | Removing tls-port or leaving the plaintext port open | Credentials are sent unencrypted otherwise |
| Kafka | A listener mapped to PLAINTEXT, or no setting for the inter-broker protocol | The documented default for the inter-broker protocol is PLAINTEXT |
| Kafka | The controller listener sharing a name with the inter-broker one | The documentation says they cannot be the same |
| RabbitMQ | A guest account made reachable remotely, or new ports exposed | See the RabbitMQ guides linked below |
| SQS | Principal set to star, or a service principal without a source condition | Star means anyone, including anonymous callers |
| Celery | accept_content widened beyond JSON | Pickle is unsafe for untrusted senders |
Steps to set it up
- Put configuration in the repository: redis.conf, broker properties, infrastructure code for queue policies. If it lives only on servers, nobody can review it.
- Write down the rules as plain statements: no PLAINTEXT listener in production, no Principal star without a condition, and so on.
- Turn the rules into automated checks. A simple search over changed files is a good first version. Policy-as-code tools do the same with less noise.
- Make the check required, so the merge button stays disabled when it fails.
- Provide an exception path with an owner, a reason and an expiry date, because some rules will have real exceptions.
- Add a short human checklist to the pull request template for what automation cannot see.
- Test the checks by opening a pull request that breaks each rule on purpose.
A short human checklist
- Who can reach this broker after the change?
- Does every client authenticate, and with its own identity?
- Is traffic encrypted, including replication and cluster links?
- What can the narrowest credential do?
- Which version are we running, and is it in an advisory range?
Keep related guides handy
Link reviewers to short guides so the rules are not folklore: Redis exposed to the internet, Kafka allow.everyone.if.no.acl.found risk, RabbitMQ guest user and the SQS Principal star guide.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request gate blocks a change and reports why, and think about which broker rules you would put behind it.
Safeguard's policies, gates and guardrails can enforce checks like these on pull requests, and the free scan can start with your dependency inventory.
Quick check
Do automated checks replace human review?
No. Automation catches known bad patterns. Reviewers still judge intent, such as whether a new consumer should exist at all.
What if the config lives in a cloud console and not in code?
Move it into infrastructure code where you can, or export it on a schedule and diff it. Unreviewed console edits are the gap this process closes.
Sources
- Redis security
- Listener Configuration, Apache Kafka 4.1 documentation
- Basic examples of Amazon SQS policies
- Security, Celery 5.6 documentation
Last reviewed: 19 October 2026.
