Watch
0
0
Fork
You've already forked hyperhive
0

stop writing and attaching per-agent and per-hive bao policies

This commit is contained in:
atlas 2026-10-26 23:02:08 +01:00
commit 139007e656

View file

@ -369,35 +369,38 @@ that mount's one role for a `hive-agent-<agent>` client certificate at agent
creation. Host roles never pin that CA and agent roles pin only it, so an
agent's certificate opens that agent's own `swarm/agents/<agent>/*` and
nothing else: `read` on the values there and `list` on their names.
`swarm-controller` writes that policy at agent creation and rewrites every
agent's at its own start, so a change to it reaches existing agents with the
next controller restart.
The agent's cert-auth role attaches a second policy, `hive-agent`, shared by
all agents. It states the same rule with `{{identity.entity.name}}` where the
per-agent policy has the agent's name, so the rule is one document. For that
the controller names each agent's identity entity after the agent: at agent
creation, and for every agent at its own start, it reads the cert mount's
All agents share one policy, `hive-agent`, which the agent's cert-auth role
attaches and no other. It states the rule with `{{identity.entity.name}}`
where an agent's name would go, so the rule is one document and a change to it
is one write. `swarm-controller` writes it at agent creation and at its own
start.
For that the controller names each agent's identity entity after the agent: at
agent creation, and for every agent at its own start, it reads the cert mount's
accessor and creates the entity `<agent>` with the alias `hive-agent-<agent>`,
or renames the entity a first login created under a generated name. When the alias
sits on any other entity, the controller logs an error and changes nothing. It needs
the `identity/` and `sys/auth/cert` grants in `swarm-bao.nix`'s
`controllerPolicyText` for that. Without them it logs a warning and the agent
keeps working through its own policy, which stays attached until every agent
has its entity. An agent's role gains `hive-agent` at its next certificate
mint.
sits on any other entity, the controller logs an error and changes nothing, and
that agent reads nothing until an operator resolves it. It needs the `identity/`
and `sys/auth/cert` grants in `swarm-bao.nix`'s `controllerPolicyText` for that.
A hive's cert-auth role `hive-<hive>` likewise attaches a second policy,
`hive-hives`, shared by all hives. A hive's certificate carries its bare name as
A cert-auth role that predates the shared policy may still name a policy
`hive-agent-<agent>`. The controller no longer writes or attaches these. The
objects stay in the store and keep granting what they did, to a token that
already carries them and to a role not yet rewritten. A live agent's role is
rewritten at its next certificate renewal.
A hive's cert-auth role `hive-<hive>` attaches one policy, `hive-hives`, shared
by all hives. A hive's certificate carries its bare name as
the common name, which is the login's alias name, so hives need no entity:
the policy states the hive's own path as
`swarm/hives/{{identity.entity.aliases.<accessor>.name}}/*`, where `<accessor>`
is the cert mount's accessor. The controller reads the accessor at its own start,
writes the policy, and attaches it when it rewrites the roles. No hive name can
writes the policy, and rewrites the roles to attach it. No hive name can
spell `hive-hives`: it would be a hive called `hives`, and
`reserved-hive-fragments.nix` refuses the substring `hive`. When the controller
can't read the accessor or write the policy it logs a warning and the role
attaches the hive's own policy alone, which stays attached.
can't read the accessor or write the policy it logs a warning and leaves the
roles untouched, so a role that names a `hive-<hive>` policy keeps it.
### Per-principal identities