Broker Security Controls

A client proves itself with a shared secret through a salted challenge-response password exchange, with a client certificate, with a directory-issued or issuer-signed short-lived token, or with delegated platform identity where it holds no secret at all.

Volume-level encryption beneath the broker stops bytes that leave the cluster: a removed drive, a copied volume image, replaced hardware. It stops nobody who connects, because the storage layer decrypts beneath the broker process, which then serves plaintext to any principal holding a grant.

Whole record payloads, their keys and the cluster's coordination traffic. Where copies are kept by nodes forwarding records to each other, that hop carries every record again for each extra copy, continuously, for as long as the cluster runs.

Brokers separate far more than reading and writing: creating a stream, deleting it, changing its settings, listing or describing names, recording a read position, and cluster-wide administration are distinct rights. Teams that grant only two end up granting all of them.

Authentication is configured per address, not per cluster. A broker answers on several separately-configured endpoints — a public client edge, an internal or administrative one, and the node-to-node hop — and the internal ones are the ones nobody went back to tighten.

Every node must already accept both the outgoing and the incoming credential. Clients reconnect to whichever member answers, so a trust set widened on only some nodes produces intermittent refusals rather than a clean, visible break.

Two properties. A principal with write access to the trail can edit the account of itself, so the records stop being evidence; and the trail dies with the cluster it describes. Ship it off-cluster, append-only, under different custody.

The cluster's own connection and authorization-decision records, read over an observation window longer than the slowest client's reconnect interval, and only if the two credentials are distinguishable in them. They miss every holder that has not connected during that window.

A broker's audit trail holds connection records — who connected, from where, on which endpoint — and authorization-decision records. Most deployments keep only the refusals, so the trail rarely shows who successfully read a stream.

Because expiry is a date shared by everything issued in the same batch: every holder loses the right to connect at the same moment. Where the node-to-node hop uses material from that batch, replication stops alongside the clients.

The decision sits on the request-serving path, so a complete trail costs work per authorized operation and produces volume comparable to the traffic itself. Narrower options: refusals only, a named set of sensitive streams or principals, one record per session, or sampling.

Because a grant whose resource is a name fragment is matched at request time against whatever names exist then, not against the names that existed when it was written. Every stream created later under that fragment is covered the moment it appears.

Authentication is an event, not a state: a long-lived connection keeps the principal it got at connect. Some designs close it at expiry, some re-authenticate in place, some never re-check — so expiry usually bites at the next reconnect.

The cluster's own access changes. Volume-level encryption leaves the broker and every grant holder reading plaintext; payload encryption by the writer leaves the cluster holding ciphertext it has no encryption key for, so the threat it answers is the operator and the grant table themselves.

At every node the record passes through. An encrypted connection protects one leg; the node decrypts to place, append and retain the record, and re-encrypts it for each reader later — so the protection has gaps wherever the cluster holds the bytes.

Because the bootstrap administrator is checked before the grant table, not against it. The cluster skips evaluation entirely for that identity, so reading the rules tells you nothing about the one principal that can do everything.

The broker trusts the platform's signer, not the client. It checks a short-lived signed statement about the workload — who signed it, that it is current, that it names this cluster — and derives the principal from it.

That service's connection predated the withdrawal and was never re-authenticated, so it kept working on a credential the cluster no longer accepts. The redeploy forced a fresh connection, which is the first moment the withdrawal was actually tested for it.

It has given up everything that depends on reading inside a record: selection by content, cluster-side transforms, content-derived routing, and any inspection during an incident. What survives is whatever sits outside the ciphertext — the partitioning key, sizes, timestamps and counts — and that is now the only handle anyone has.

Encryption forces the node to handle bytes it previously never touched, closing the copy-free read path from stored file to network. The added work scales with bytes shipped, and a history replay ships the most bytes fastest; a caught-up reader trickles.

A refusal-only trail is negative evidence and cannot show use. Prune by connection records first, measure positively for a time-boxed window on the streams under review, then withdraw in stages — and make grants expire so the burden shifts to justifying renewal.

The broker's own evaluation expresses stream operations precisely and survives the platform being unreachable, but is a second permission system to run. Platform evaluation unifies the estate and loses granularity. Most large estates end up with both.

Decide on first delivery, failure shape, identity granularity and reach rather than abstract strength: how a new client gets its credential with nobody copying it, whether failure is a quiet leak or a scheduled outage, and which clients can implement it.

Custody decides who can read the stream's history, including records written long before the current custodians arrived. It is an access decision and a durability decision at once: withdraw or lose the encryption key and the bytes survive as bytes nobody can open, whatever the grant table says.