Security hardening

This checklist orders the hardening decisions BROKA leaves to you: broker credentials, environment write policy, key custody, network posture and TLS. Who may change what, and how the audit trail is kept, is the other half, on Access and audit hardening.

BROKA arrives closed rather than open — it ships no default credentials, refuses to start on a missing secret, and records every change it makes and every request it refuses. What follows are the decisions left to you, in the order worth making them.

1. Give BROKA the narrowest broker credentials that work

This is the single highest-value decision, and it is the one BROKA cannot make for you.

Everything BROKA does on a broker, it does as the identity you gave it. Its guardrails run in BROKA — they are what stops a person, and they are not enforced by your broker. So the credential in a connection should be able to do what you intend to do through BROKA, and nothing more.

In practice: a connection used for reading should authenticate as an identity that can only read. If you want BROKA to be able to delete topics, that is a deliberate grant to a specific connection, not a property of every connection you register.

BROKA supports this rather than working around it. When an identity is missing something, the console says which surfaces will be unavailable at the moment you test the connection, instead of showing you empty screens later.

2. Decide each environment's policy, and mark production read-only if it should be

An environment's guard policy is not a permission and no role overrides it. Marking production read-only means every write is refused there — for administrators too.

This is the control to reach for when the answer to "who should be able to write to production from a web console?" is "nobody, ordinarily". It is stronger than a role because it does not depend on getting every role right, and it survives someone being given a broader role next quarter.

Individual connections carry their own read-only switch as well, which applies even inside an open environment — the way to freeze one cluster during a migration without freezing its neighbours.

3. Protect the installation's key material

Connection credentials are encrypted with a key of their own, which is itself wrapped by the installation's key-encrypting key. That key is never in the database. A copy of your database, taken by any means, does not contain the material to decrypt what is in it.

Which means the key belongs somewhere your database backups are not. Treat it as the one secret whose loss is unrecoverable and whose disclosure undoes the rest.

Secrets are never returned by the API — reading a connection tells you which kinds are set, never their values — and when the one place a secret becomes plaintext decrypts it to serve a request, that request's audit entry says which connection's secret and of which kind, never the value. When it decrypts one for its own work — a list snapshot, an alert check, an alert being sent — it records that as an entry of its own, once an hour per secret.

BROKA also refuses to let a credential end up in the wrong place: a connection's configuration document is rejected if it carries anything named like a credential, at any depth, with a message pointing at the field that should hold it.

4. Network posture

BROKA sends nothing on its own. No telemetry, no usage reporting, no call home. Left alone it talks to your database, your brokers, and the browsers of the people using it — and nothing about your brokers, topics, queues, messages or users is ever sent anywhere by the product's own initiative.

What can leave is what you configure. That is a short list, and it is worth having in full:

	What goes out, unprompted
Community	Nothing. No licence, no activation field, nothing to call.
Commercial, activated offline	Nothing. You paste a signed key; the online path is not attempted at all.
Commercial, activated online	One HTTPS call to activate, then roughly one a day to refresh. It carries your licence and installation identifiers — never anything about your brokers or their contents.

So a Community installation, and a commercial one activated offline, can run in a network with no outbound path at all. A commercial installation activated online needs to reach the licence server and nothing besides; if that is not acceptable in your network, activate offline instead — the two paths issue the same licence.

Three things you can switch on do send outward, and each is worth deciding deliberately.

A notification channel (Settings › Integrations) posts to Slack, Microsoft Teams or a webhook of your choosing — those three in Commercial — or through your own SMTP relay. What rides on it is the severity, the rule, the metric, the comparison and threshold, the connection's name and the names of the targets that breached — so resource names travel to whatever endpoint you named. Message contents never do. On an estate where a topic or queue name is itself information, that is the sentence to read twice before configuring a channel that leaves your network.

The SMTP relay is the second: the installation sends mail through the server you give it, and you choose that server.

Audit forwarding to an HTTP endpoint, set in the deployment environment, is the third: every sealed audit event is posted to the address you give it, with the token you give it. Forwarding to a file, or in Commercial to one of your own Kafka or RabbitMQ connections, stays inside your estate.

None of them exists until you create it, and none is reached by any default.

The MCP server (Commercial) goes the other way: an AI assistant connects in, and BROKA connects out to no AI service. It adds no port — it is served at /api/mcp on the console's own published port — and it answers only while Settings ▸ MCP is on; while it is off, that address answers as if it did not exist. A request to it from a web page on another origin is refused.

Where it does open a connection you configured — a metrics port, a schema registry, a Connect worker — the address is checked before it is used: link-local and cloud-metadata addresses are refused, so a mistyped or hostile address cannot turn the console into a probe of its own network.

Certificate verification is a per-connection setting on every platform, and worth checking on each one rather than assuming: BROKA verifies by default everywhere, and turning verification off is something a person does deliberately, connection by connection. Review the connections you have for any that skip it.

An environment can also forbid it outright, on every platform that can express it: one that disallows insecure TLS refuses to save such a connection, and disables the option in the form rather than accepting it and rejecting it later. Kafka spells it as ssl.skipVerify (and the same on an embedded Connect cluster), Redis as tls.verifyPeer / tls.verifyHostname, and RabbitMQ as tls.skipVerify — turning any of them off is refused. On RabbitMQ, as on Redis, a private-CA broker is reached by uploading its CA certificate to the connection, which keeps verification on rather than relaxing it. Artemis and Memcached have no such option to forbid: Memcached is not reached over TLS at all, and a private-CA Artemis is reached by installing the CA in the broker service's trust store, not by relaxing a connection.

5. Two operational habits

Browse rather than consume. Reading a Kafka topic in BROKA never joins a consumer group and never commits an offset, so it cannot disturb a running application. On RabbitMQ, reading a message off a queue genuinely takes it — the console says so before you confirm. Knowing which of the two you are doing is the difference between investigating an incident and extending it.

Review access on a schedule, not after an incident. The effective-access report (Commercial) and the evidence pack exist to make that a short task rather than a project.