Skip to content

PATTERN Cited by 1 source

Caveat for privilege separation

Pattern

Give a broadly-privileged subject (e.g., an orchestrator that must touch many tenants) a token that carries a third-party caveat dischargeable only by proving tenant-specific authority. The subject can perform tenant-scoped operations, but only for the tenant whose discharge they can currently obtain.

Net result: one physical token, fleet-wide, but access is partitioned per-request by the caveat. A compromise of the token leaks nothing unless the attacker can also produce the per-tenant discharge.

Canonical instance: Fly.io flyd ↔ Pet Semetary

From sources/2025-03-27-flyio-operationalizing-macaroons:

Setup. Pet Semetary is Fly.io's in- house Vault replacement — it issues its own Macaroons with its own permissions system. User secrets (e.g., Postgres connection strings) live in Petsem.

Problem. flyd, the orchestrator running on every worker, needs to inject the right user's secrets into a Fly Machine at boot time. But giving every flyd a Macaroon that reads every user's secrets would collapse isolation — "every worker is equally privileged."

Solution. The read-secret Macaroon flyd holds has a third-party caveat attached "dischargeable only by talking to tkdb and proving (with normal Macaroon tokens) that you have permissions for the org whose secrets you want to read."

Property. "Once again, access is traceable to an end-user action, and minimized across our fleet."

Why this is better than the alternatives

  • vs. per-worker read tokens: operationally brittle (hot add/remove), doesn't reduce cross-tenant leakage from a single worker compromise.
  • vs. flyd calls Petsem on behalf of user: requires flyd to hold or synthesize user-level credentials, pushing more hazmat onto workers.
  • vs. per-request Petsem auth handshake: doesn't achieve the "traceable to end-user action" property — flyd could be tricked into synthesizing its own discharge.

The third-party caveat + discharge dance forces every secret read to be tied to a currently-presentable user authority chain, even though the token transport goes through an orchestrator service.

Generalization

This is a specific application of Macaroon third-party caveats to the problem of broadly-deployed, narrowly-authorized service principals. The pattern generalizes to any setting where:

  • A service must access per-tenant resources.
  • You don't want the service to hold per-tenant credentials at rest.
  • You have an authority that can mint discharges proving tenant membership on demand.

Companion pattern

See patterns/third-party-caveat-strip-for-service-token for the inverse operation — the authority removing a third-party caveat to produce a stripped service token the holder can further attenuate.

Seen in

Last updated · 200 distilled / 1,178 read