| Filename | Latest commit message | Latest commit date |
|---|---|---|
1261b525d6
A swarm runs one homeserver and every hive on it logged in as the same `@hive:` localpart, holding the same access token out of one swarm-wide store path. That is one matrix identity for N hives: the homeserver cannot attribute an action to the hive that took it, and revoking one hive's standing revokes every hive's. Three changes, and the third is the one that makes the other two real: - **The localpart carries the hive's name** (`hive-<hive>`), derived in one place, `swarm_secret_client::matrix::hive_localpart`. `hive-matrix.nix` renders the same string as the appservice registration's `sender_localpart`, so the shared account stops being created rather than merely stops being used. - **The store path is templated by hive**, not a constant. The "a swarm runs one homeserver, so this is a constant rather than a parameter" rationale went with it; it stopped holding the moment two hives shared the homeserver it describes. - **The path moved out from under the grant every hive has.** It sat at `swarm/services/matrix/sender-token`, inside the `secret/data/swarm/services/*` read stanza `policy::render` gives every hive. It now sits under that hive's own stanza, `secret/data/swarm/hives/<hive>/*`, which interpolates the reader's name — so a hive reads its own token and is refused another's. The policy renderer itself is unchanged: narrowing the `services/*` grant would break the OIDC-secret read it exists for, and moving the credential is what this needed instead. A policy test walks the rendered stanzas and asserts none of hive alpha's covers hive beta's sender token, so a later stanza that widened it fails here. `swarm-matrix-ctl` takes a new required `MATRIX_MINT_HIVE` and writes that hive's path; its store grant in `swarm-bao.nix` follows, scoped to one hive's leaf via the new `deploy.bao.matrixCtlHiveName` (defaulting to this host's `hiveName`) rather than a `hives/*` wildcard, which would hand the matrix container every hive's token back. Migration: no outage at deploy. `ensure_hive_user` short-circuits on the local token file, so a hive keeps running on what it has; with no such file it reads the new per-hive path, finds nothing, and falls through to the existing register-or-appservice-login ladder against its own localpart — which needs only the per-hive `as_token` on local disk. The old shared object is read by nothing afterwards. Rooms do not follow the identity, and that is the one operator step; both ways out are written into `docs/integrations/matrix.md`. No admin standing is granted to the per-hive accounts: `admin_execute` stays empty and the assertion pinning it is untouched. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
swarm-secret-client
Reading and writing a swarm credential in the secret store, over vaultrs.
The HTTP is that crate's job. What this one owns is the agreements both
ends of the store have to state identically: where a credential lives, which
field its bytes are in, and how this deployment's environment becomes a
logged-in client.
The surrounding picture — which secret is minted where, and why delivery is a
copy rather than a bind mount — is docs/swarm/secrets.md.
Why a crate and not a module per binary
The store has two Rust ends and they are peers: the swarm controller writes a credential, a hive reads it. Neither is senior to the other, so a path formatted at each call site is an agreement with no owner — it holds right up until one side is edited alone, and then it fails as a missing key rather than as a mismatch.
The third end is what settles it. nix/host-modules/glue-matrix-bao-token.nix
reads the store with bao kv get -field=value. That reader is a shell line in
a nix module: it cannot be renamed by the same refactor as a Rust struct, and
no Rust test reaches it. So the field name is pinned by a test against the
serialised literal rather than left to the struct definition.
The identity is a certificate, and the role is the hive's name
Authentication is the store's cert auth method.
nix/host-modules/glue-bao-tls.nix mints the client certificate with its CN
set to the hive's name, because a cert-auth role matches on the CN. So
cert_role is not a free choice for the caller: a hive passes its own name,
and the policy attached to that role is what scopes what it may read.
The listener's tls_require_and_verify_client_cert is a different thing and
not a substitute. It decides who may open a connection; it says nothing about
who the connection belongs to, and a store with the option set and no cert
mount configured refuses every login made here. That refusal is what
Error::Vault out of connect means.
Configuration
Settings::from_env reads BAO_ADDR, BAO_CLIENT_CERT, BAO_CLIENT_KEY,
and the optional BAO_CACERT.
The BAO_ spellings are read explicitly rather than left to vaultrs. Its
own defaults look for VAULT_ADDR / VAULT_CLIENT_CERT / VAULT_CLIENT_KEY,
which no unit in this tree sets. Falling through to them builds a client with
no identity at all, and that surfaces as a TLS handshake failure — a place
that names neither the variable nor the reason.
Empty is as absent as unset. systemd renders an unset nix option as
Environment=BAO_CACERT=, so empty is the shape a missing value arrives in.
The certificate and key are paths, not values, and are read at connect time — same rule as every other credential in this tree, for the same reason: a value in a nix expression is rendered into the world-readable store.
Reading the environment is separate from connecting (Settings::from_lookup)
because every one of those failures is a misconfiguration an operator has to
read an error about, and none of them needs a reachable store to happen.
Names that arrive from elsewhere
matrix::account_path is fallible, which for a string formatter needs saying:
its segments are an agent name from the topology and an account name from that
agent's own config. A / turns one agent's segment into another agent's
directory and .. walks out of the prefix entirely, so the charset it accepts
is deliberately narrower than what the store would.
One module per kind of secret
client moves whatever type a caller names; it decodes nothing itself. What a
stored object holds is stated in the module that also builds its path —
matrix today, and a second kind of swarm secret gets a module beside it.
The split is deliberate. A single shared struct that grows one field per consumer ends up carrying, on every path, a field only one path's reader has ever heard of; and the two things a kind of secret must pin — where it lives and what is in it — are one agreement that reads worse split across modules.
What this crate does not do
It has no opinion on what a caller may read. That is the policy attached to the cert role, and it lives in the store.
It holds the token minted at login and renews nothing. A handle is built per credential, so the login is the cheap part of a rare operation — a caller that wanted to keep one alive across a token's lifetime would need more than this.