serviceVMs identities: root is the only account on a service VM #41

New issue

Closed

opened 2026-10-07 02:21:09 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 02:21:09 +01:00

The identity template gains a serviceVMs set, empty for now, so the framework can compose type = "service" machines whose only login is root over the hypervisor's keys. Part of allod/strategy#65 (the forge VM is the first such machine); the type's inventory rules and builder land in allod/inventory and allod/archetypes under their own issues.

Primary goals:

identity.serviceVMs — like privacyVMs but without a username: a service VM has no operator account. The template declares the set empty.
lib.serviceIdentities — one identity per entry carrying username = "root", folded into lib.vmUsernames beside devIdentities and privacyIdentities, so every hypervisor script that logs in as the identity's username (verify-vm, rebuild-vm, bootstrap-vm) reaches root on a service VM unchanged.
Host keys as for any guest — a service VM's host key goes through machine-host-keys.json, secrets/vm-host-keys/<name>-ssh.age and lib.vmHostKeySecretFiles exactly as privacy and dev VMs do; nothing new to learn for getting-started.sh.
Never a token recipient — secrets.nix derives recipients from devVMs and forgeAccess; a service VM is not in that set and the checks keep it so.
Checks — the identity-shape and username-collision checks cover serviceVMs (a service VM named like a hypervisor hostname still fails evaluation); credential-inventory and hypervisor-recipient-coverage stay green; the README's export table gains the row.

Current state and specifics

flake.nix builds privacyIdentities from identity.privacyVMs with inherit (vm) username, and vmUsernames from devIdentities // privacyIdentities plus the hypervisor identities through mkVmUsernames, which refuses a guest name colliding with a hypervisor hostname. identity.nix declares privacyVMs.privacy-1 = { username = "privacy"; } and an sshHosts entry for it with user = "privacy". The archetypes framework reads secrets.lib.serviceIdentities or {} so a fork that has not taken this change still evaluates, and asserts machine names and identity names match, so a service machine in inventory needs its serviceVMs entry here.

Scope

In: identity.nix, flake.nix, the checks named, the README. Out: the forge entry itself, its host key ciphertext and its sshHosts line, which arrive with allod/strategy#65's next slice; the dev VM's forge key pair, same slice.

The identity template gains a `serviceVMs` set, empty for now, so the framework can compose `type = "service"` machines whose only login is root over the hypervisor's keys. Part of allod/strategy#65 (the forge VM is the first such machine); the type's inventory rules and builder land in `allod/inventory` and `allod/archetypes` under their own issues. Primary goals: - **`identity.serviceVMs`** — like `privacyVMs` but without a username: a service VM has no operator account. The template declares the set empty. - **`lib.serviceIdentities`** — one identity per entry carrying `username = "root"`, folded into `lib.vmUsernames` beside `devIdentities` and `privacyIdentities`, so every hypervisor script that logs in as the identity's username (`verify-vm`, `rebuild-vm`, `bootstrap-vm`) reaches root on a service VM unchanged. - **Host keys as for any guest** — a service VM's host key goes through `machine-host-keys.json`, `secrets/vm-host-keys/<name>-ssh.age` and `lib.vmHostKeySecretFiles` exactly as privacy and dev VMs do; nothing new to learn for `getting-started.sh`. - **Never a token recipient** — `secrets.nix` derives recipients from `devVMs` and `forgeAccess`; a service VM is not in that set and the checks keep it so. - **Checks** — the identity-shape and username-collision checks cover `serviceVMs` (a service VM named like a hypervisor hostname still fails evaluation); `credential-inventory` and `hypervisor-recipient-coverage` stay green; the README's export table gains the row. ### Current state and specifics `flake.nix` builds `privacyIdentities` from `identity.privacyVMs` with `inherit (vm) username`, and `vmUsernames` from `devIdentities // privacyIdentities` plus the hypervisor identities through `mkVmUsernames`, which refuses a guest name colliding with a hypervisor hostname. `identity.nix` declares `privacyVMs.privacy-1 = { username = "privacy"; }` and an `sshHosts` entry for it with `user = "privacy"`. The archetypes framework reads `secrets.lib.serviceIdentities or {}` so a fork that has not taken this change still evaluates, and asserts machine names and identity names match, so a service machine in inventory needs its `serviceVMs` entry here. ### Scope In: `identity.nix`, `flake.nix`, the checks named, the README. Out: the `forge` entry itself, its host key ciphertext and its `sshHosts` line, which arrive with allod/strategy#65's next slice; the dev VM's forge key pair, same slice.

vnprc-agent referenced this issue from allod/strategy

2026-10-07 02:21:45 +01:00

Define the managed service machine architecture #45

vnprc-agent referenced this issue

2026-10-07 05:08:05 +01:00

The forge machine's identity and host key #42

vnprc-agent referenced this issue from allod/strategy

2026-10-07 05:08:19 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65