Support per-target bearers in pi-provider #36

New issue

Open

opened 2026-09-01 19:47:23 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-01 19:47:23 +01:00

Teach pi-provider to give a single target its own bearer for a provider, so an operator can adopt the per-target credentials that allod/secrets issue #16 makes expressible without hand-editing a registry or an Age ciphertext.

Primary goals:

Add a target with its own bearer — one command puts a machine on an existing provider and prompts for a bearer only that machine will hold, instead of extending a shared credential's target list.
Migrate a shared credential — a documented, resumable path from one credential fanned out across several targets to one credential per target, since the operation needs every bearer in hand at once.
Keep the ciphertext narrow — each per-target ciphertext is encrypted to that machine's host keys and the hypervisor's, and the tool refuses to widen a recipient set it did not intend.
Preserve the existing shapes — a genuinely shared service credential stays a first-class arrangement; per-target is an option, not a replacement.

Current state

retarget is the only command that changes which machines reach a provider, and it is whole-credential by construction: scripts/pi-provider:119 documents --target as a replacement list, the retarget branch plans an encrypted token for every token of the credential, and prompt_and_encrypt at :1185 takes one hidden prompt per planned token before writing anything. collect_recipients at :1086 then reads one recipient set for the credential and asserts every token shares it, which is exactly right while a credential has one bearer for all its targets and has no meaning once each target has its own.

So there is currently no way to say "add this machine, with this bearer, leave the others alone". Extending the target list re-encrypts the one shared ciphertext to a wider recipient set, which is the behaviour the linked contract issue exists to make optional.

Ordering

This cannot be designed before allod/secrets issue #16 settles the registry shape, because the command surface follows from it: whether a target carries a credential reference, and whether a provider's credentials are addressed by target, determines whether this is a new flag on an existing command or a new command. Filed now so the tool half is tracked rather than discovered late; do not start it while the contract shape is open.

Scope

In scope: the command surface for per-target bearers, the recipient assertions that keep each ciphertext narrow, the migration path for an existing shared credential, and the dry-run output that shows an operator exactly which machines gain and lose access before anything is written.

Out of scope: the contract change itself, tracked in allod/secrets issue #16. Also out of scope: any change to how a shared credential behaves for deployments that keep using one.

Teach `pi-provider` to give a single target its own bearer for a provider, so an operator can adopt the per-target credentials that `allod/secrets` issue #16 makes expressible without hand-editing a registry or an Age ciphertext. Primary goals: - **Add a target with its own bearer** — one command puts a machine on an existing provider and prompts for a bearer only that machine will hold, instead of extending a shared credential's target list. - **Migrate a shared credential** — a documented, resumable path from one credential fanned out across several targets to one credential per target, since the operation needs every bearer in hand at once. - **Keep the ciphertext narrow** — each per-target ciphertext is encrypted to that machine's host keys and the hypervisor's, and the tool refuses to widen a recipient set it did not intend. - **Preserve the existing shapes** — a genuinely shared service credential stays a first-class arrangement; per-target is an option, not a replacement. ### Current state `retarget` is the only command that changes which machines reach a provider, and it is whole-credential by construction: `scripts/pi-provider:119` documents `--target` as a replacement list, the retarget branch plans an encrypted token for every token of the credential, and `prompt_and_encrypt` at `:1185` takes one hidden prompt per planned token before writing anything. `collect_recipients` at `:1086` then reads one recipient set for the credential and asserts every token shares it, which is exactly right while a credential has one bearer for all its targets and has no meaning once each target has its own. So there is currently no way to say "add this machine, with this bearer, leave the others alone". Extending the target list re-encrypts the one shared ciphertext to a wider recipient set, which is the behaviour the linked contract issue exists to make optional. ### Ordering This cannot be designed before `allod/secrets` issue #16 settles the registry shape, because the command surface follows from it: whether a target carries a credential reference, and whether a provider's credentials are addressed by target, determines whether this is a new flag on an existing command or a new command. Filed now so the tool half is tracked rather than discovered late; do not start it while the contract shape is open. ### Scope In scope: the command surface for per-target bearers, the recipient assertions that keep each ciphertext narrow, the migration path for an existing shared credential, and the dry-run output that shows an operator exactly which machines gain and lose access before anything is written. Out of scope: the contract change itself, tracked in `allod/secrets` issue #16. Also out of scope: any change to how a shared credential behaves for deployments that keep using one.