The volume beneath a broker cluster is encrypted at the storage layer — which reader does that stop, and which does it not?

## What "at rest" means under a broker A broker is a storage system that happens to speak a messaging protocol. From the moment a write is accepted until retention removes it, the record sits as bytes on a node's volume — and not on one volume: - **every copy has its own storage.** A stream kept in several copies exists on as many volumes, on as many machines, in as many failure domains. The number of physical devices carrying your records is a multiple, not one. - **the bytes sit for as long as the stream keeps history**, which on some platforms is hours and on others months. Whatever that window is, it is the window during which a drive can be lost, replaced or copied. - **hardware turns over.** Nodes are replaced, volumes are resized and re-created, images are taken. Each of those is a moment when bytes exist somewhere other than where you think they do. That is the exposure volume-level encryption beneath the broker is aimed at, and it is a real one. ## What the control actually does The encryption happens **underneath** the cluster, in the storage layer. The broker process issues an ordinary read and gets plaintext back; it has no encryption step, no key and usually no knowledge that the control exists. That single fact determines everything about its reach: 1. Bytes that leave the system **as bytes** are unreadable — the drive, the image, the discarded device. 2. Bytes reached **through the system** are plaintext — because the system is doing the decrypting on your behalf, for whoever asks. ## Who it stops, and who it does not | Who wants the records | Volume-level encryption beneath the broker | | --- | --- | | A drive removed from a decommissioned node | Blocked — the bytes are meaningless off the machine | | A copied volume image or a lifted storage snapshot | Blocked, provided the copy carries no usable key | | Hardware returned to a vendor or resold | Blocked | | A client that authenticates and holds a grant | **Reads plaintext**, including retained history | | A principal whose grant turned out wider than intended | **Reads plaintext** | | Anyone with access on a running node | **Reads plaintext** through the mounted filesystem | | The operator of a rented cluster | **Reads plaintext**; their processes are inside the boundary | The left column is a physical-custody threat. The right column is an access-control threat, and it is answered by grants, by authentication and — where the operator themselves must be excluded — by having the writer encrypt payloads before the cluster ever sees them. ## Why this bites harder on a broker than on a typical service Two differences matter in an interview answer: - **A broker holds history, not a row.** One over-broad grant on a request-serving service leaks what the caller asks for. The same mistake on a stream hands over everything still retained — every record written since the window opened, at full speed, in one read. - **The record outlives the reason it was written.** People who could once read a stream leave; the records stay. A control that stops only a stolen disk does nothing about the grant table that has only ever grown. ## What varies across platforms Do not state this as one model. **On a cluster you run**, volume encryption is an infrastructure choice made beneath the broker, and it is your job to confirm it is on for *every* node's storage, including the copies you rarely look at. **On a rented cluster**, many operators apply it to the whole tier as a default; some let you supply the key that protects the storage, some hold it entirely themselves, and some expose nothing about it at all — which is exactly the difference that decides whether the tier's own staff are inside or outside your threat model. Platforms also differ in whether anything finer exists: some offer nothing between "the volume is encrypted" and "encrypt it yourself before sending", while others let a writer encrypt individual parts of a record. ## How to answer it Name the threat model first, then the residue. "It protects bytes that leave the cluster — a disk, an image, returned hardware. It protects nothing that comes in through the front door, because the storage decrypts beneath the broker and the broker serves plaintext to anyone with a grant. It has to be on for every replica's volume, and if I need the cluster and its operator excluded as well, the writer has to encrypt the payload itself." That answer shows you know a control's boundary, which is the thing being tested.