portable ephemeral state #493

New issue

Closed

opened 2025-08-15 09:34:55 +02:00 by kiara · 1 comment

kiara commented

2025-08-15 09:34:55 +02:00

Owner

In order to migrate data between instances (#100), we will need to be able to transfer relevant (secret) ephemeral (#314) state.

implementation notes

state used in systemd's LoadCredentials we could use from openbao by systemd-openbao (untested fileSecrets provider).
(non-JSON formats we could maybe derive from such credentials using nix-templating.)

systemd-openbao details

importing systemd-openbao
openbao
AFNix systemd-openbao wrapper secrets-agent
TF privilege levels, e.g. as used in AFNix:
- superadmin (CRUD, gate behind e.g. 2FA + 1 colleague validating actions, ideally not network-exposed)
- admin (?)
- common (read access, any SPIFFE-authenticated machine, see #633)
openbao plugins
- built-in
- ~~external (vault-plugin-...)~~ - dupe of built-in?
older openbao + systemd work

generating (non-systemd?) state may need #314, centralizing (secret) ephemeral nix data, incidentally rendering it portable.

examples:

service credentials: ~~potentially already restored thru back-up?~~ vars
~~[ ] ssh keys: optional?~~
~~[ ] root/user passwords: optional? (probably users should not have ssh/sudo access anyway)~~

back-ends:

non-local could facilitate migration (#100):

vars
- ~~on-machine (local)~~
clan-core (nix, python)
- ~~sops (local)~~
- ~~password-store (local)~~
- ~~vm (local)~~
- ~~fs (local)~~
custom: integrations with other back-ends possible, e.g.:
- ~~valkey (fwiw, afaict not available thru TF back-ends)~~

TF state - for our purposes might help keep vars state in the same place as orchestrator state
openbao
- also unofficially available as TF back-end, see #515
stretch goal: implement vars openbao back-end (c.f. #314) - landed in #1009

In order to migrate data between instances (#100), we will need to be able to transfer relevant (secret) ephemeral (#314) state. ## implementation notes state used in [systemd's `LoadCredentials`](https://systemd.io/CREDENTIALS/) we could use from openbao by [`systemd-openbao`](https://git.lix.systems/the-distro/systemd-openbao.git) ([untested `fileSecrets` provider](https://github.com/KiaraGrouwstra/nixpkgs/pull/new/systemd-openbaod-provider)). (non-JSON formats we could maybe derive from such credentials using [`nix-templating`](https://github.com/Lassulus/nix-templating).) <details> <summary> systemd-openbao details </summary> - [importing `systemd-openbao`](https://git.afnix.fr/afnix/infra/src/commit/0f4a7ad40369b338a5dd88a720be773f3d357457/flake.nix#L58-L471) - [openbao](https://git.afnix.fr/afnix/infra/src/branch/main/services/vault/default.nix) - AFNix `systemd-openbao` wrapper [secrets-agent](https://git.afnix.fr/afnix/infra/src/branch/main/services/secrets-agent/default.nix) - TF privilege levels, e.g. as used in AFNix: - [superadmin](https://git.afnix.fr/afnix/infra/src/branch/main/terraform/superadmin/vault/default.nix) (CRUD, gate behind e.g. 2FA + 1 colleague validating actions, ideally not network-exposed) - [admin](https://git.afnix.fr/afnix/infra/src/branch/main/terraform/admin/vault/default.nix) (?) - [common](https://git.afnix.fr/afnix/infra/src/branch/main/terraform/common/vault) (read access, any SPIFFE-authenticated machine, see #633) - openbao plugins - [built-in](https://openbao.org/docs/plugins/#built-in-versions) - ~~[external](https://releases.hashicorp.com/) (`vault-plugin-`...)~~ - dupe of built-in? - older openbao + systemd work - [`nix-svc-secrets`](https://github.com/d-goldin/nix-svc-secrets) - [`vault-secrets`](https://gist.github.com/mkaito/ce20db29ed9c7285808c935597232bd8) - [`syringe`](https://github.com/ZentriaMC/syringe) </details> generating (non-systemd?) state may need #314, centralizing (secret) ephemeral nix data, incidentally rendering it portable. examples: - [ ] service credentials: ~~potentially already restored thru back-up?~~ `vars` - ~~[ ] ssh keys: optional?~~ - ~~[ ] root/user passwords: optional? (probably users should not have ssh/sudo access anyway)~~ <details> <summary> back-ends: </summary> _non-local_ could facilitate migration (#100): - [vars](https://github.com/Lassulus/vars/tree/main/backends) - ~~[`on-machine`](https://github.com/Lassulus/vars/blob/main/backends/on-machine.nix) (local)~~ - [clan-core](https://docs.clan.lol/reference/clan.core/vars/#clan.core.vars.settings.secretStore) ([nix](https://git.clan.lol/clan/clan-core/src/branch/main/nixosModules/clanCore/vars/secret), [python](https://git.clan.lol/clan/clan-core/src/branch/main/pkgs/clan-cli/clan_cli/vars/secret_modules)) - ~~`sops` (local)~~ - ~~`password-store` (local)~~ - ~~`vm` (local)~~ - ~~`fs` (local)~~ - custom: integrations with other back-ends possible, e.g.: - ~~[valkey](https://valkey.io/) (fwiw, afaict not available thru TF back-ends)~~ </details> - TF state - for our purposes might help keep vars state in the same place as orchestrator state - [openbao](https://openbao.org/) - also unofficially available as TF back-end, see #515 - stretch goal: implement [vars openbao back-end](https://git.clan.lol/clan/clan-core/issues/6805) (c.f. #314) - landed in #1009

Rows
Columns