jschoubben
c37d368f65
Two things, both found by trying to write a real postgres module and discovering it could not be said. A database has a superuser password, a broker an administrator, a registry an account. None of them is *for* anybody — they are not the credential a consumer is given, and the mechanism that hands those out has a consumer in the middle of it. So a module may declare what it needs and where to put it, and the mesh generates one per node, seals it, and reads it no more than it reads any other. Per node, deliberately: a module running on three machines has three passwords. One in the manifest instead would put the same secret on every machine that ever runs it, in a file anybody can read, for ever. Made once and kept, or a running database would be handed a password it was not started with; remade when the machine's sealing key changes, like everything else sealed here. A need declared and not made is refused rather than skipped, because a module whose own credential is silently absent starts, fails to authenticate, and the reason is three layers from the machine reporting it. And the provisioner can watch. That is what lets it be a module rather than a binary somebody places: run once, it needs invoking after every declaration by a timer or a unit wired to a file; watching, it is an ordinary long-running service the host already supervises. It polls rather than watching the filesystem, because the host writes atomically — the file is replaced, so a watch on the path stops seeing anything after the first replacement, and a watcher that silently stops working is worse than a poll. Credentials are compared by digest and never held: this runs for as long as the machine is up.
30 lines
1.4 KiB
SQL
30 lines
1.4 KiB
SQL
-- A secret a module needs in order to be itself.
|
|
--
|
|
-- A database has a superuser password, a broker an administrator, a registry an account. None of
|
|
-- them is *for* anybody -- they are not the credential a consumer is given, and the table holding
|
|
-- those has a consumer in its key.
|
|
--
|
|
-- **One per node**, so a module running on three machines has three passwords. A manifest that
|
|
-- carried one instead would put the same secret on every machine that ever runs the module, in a
|
|
-- file anybody can read, for ever.
|
|
--
|
|
-- Sealed to the node before it is written, like everything else here: what is stored is unusable
|
|
-- by whoever holds it, the mesh included.
|
|
|
|
create table module_secret (
|
|
node uuid not null references node(id) on delete cascade,
|
|
module text not null references module(name) on delete cascade,
|
|
-- The module's own word for it. Two secrets in one module are ordinary -- a password and a
|
|
-- token, say -- and telling them apart is the module's business, not the mesh's.
|
|
name text not null,
|
|
|
|
sealed text not null,
|
|
-- Which key it was sealed to, so a node that regenerated its key can be told what it can no
|
|
-- longer open rather than discovering it as a service that will not start.
|
|
node_key text not null,
|
|
|
|
made_at timestamptz not null default now(),
|
|
|
|
primary key (node, module, name)
|
|
);
|