ephemeral state is automatically provisioned #314

New issue

Open

opened 2025-04-19 13:03:25 +02:00 by kiara · 1 comment

kiara commented

2025-04-19 13:03:25 +02:00

Owner

our current setup has left many things hard-coded, whereas in practice there is quite some ephemeral state that should likely be generated, whether sensitive or not.

this includes at least:

automating generate-vars
- implement vars openbao back-end (see #493) - landed in #1009
- vars contract (+ openbao fileSecrets provider) - landed in #1009
prevent clashes between applications
- ports: alloc?
needed for security (#291)
- service credentials (current hardcoded / age secrets)
- garage credentials
- SSL credentials: see selfhostblocks' SSL contract (#1041) or openbao's PKI secrets engine (#87)
- machine SSH keys ((test-)machines/) - see clan module sshd or openbao's PKI secrets engine)
needed to facilitate contributions (#288)
- name servers - make configurable (offering a default)?
- users (developers, shared account) - see clan modules root-password / user-password
needed to streamline dev-ops (#224)
- NixOS system.stateVersion - see clan module state-version
~~#116: needed to automatically test proxmox~~

state scenarios:

destination	sensitive	storage	distribution
orchestration	*	openbao	nimbolus
build	no	(depends on source)	build
system	no	on-machine	vars
system	yes	on-machine (vars) -> openbao	vars -> openbao?
service	no	on-machine	(nix-templating +) vars
service	yes	on-machine (vars) -> openbao	(nix-templating +) vars -> systemd-openbao

destination	unsensitive	sensitive
orchestration	TF state	TF state
build		n/a
system	vars	openbao?
service (nix-templating +)	vars	systemd-openbao

info	sensitive	destination	source	goal
MAC address	no	build	provisioning	#116 provisioning
IP address	no	build	provisioning	#116 provisioning
architecture	no	build	provisioning	#116 provisioning
gateway	no	build	provisioning	#116 provisioning
hardware	no?	build	`nixos-facter`	#116 provisioning
authorized SSH keys	no	system	config: host	#116 provisioning
TLS/SSL certificates	yes	service	bao PKI	#116 provisioning
SSH keys	yes	system	bao PKI / vars `sshd`	#291 security
service credentials	yes	service	vars?	#291 security
`system.stateVersion`	no	build	vars `state-version`	#224 devops
name servers	no	build	config: operator	#288 contributions
user credentials	yes	build?	vars `{root,user}-password`	#288 contributions

our current setup has left many things hard-coded, whereas in practice there is quite some ephemeral state that should likely be generated, whether sensitive or not. this includes at least: - [x] [automating `generate-vars`](https://github.com/Lassulus/vars/issues/5) - [x] implement vars openbao back-end (see #493) - landed in #1009 - [x] [vars contract](https://github.com/ibizaman/selfhostblocks/issues/467) (+ openbao [fileSecrets provider](https://github.com/KiaraGrouwstra/nixpkgs/compare/contracts-automated...contracts-new-types)) - landed in #1009 - [ ] prevent clashes between applications - [ ] ports: [alloc](https://discourse.nixos.org/t/alloc-nix-a-tool-to-help-you-allocate-ranges-to-services/72603)? - [ ] needed for security (#291) - [ ] service credentials (current hardcoded / `age` secrets) - [ ] garage credentials - [ ] SSL credentials: see selfhostblocks' [SSL contract](https://shb.skarabox.com/contracts-ssl.html) (#1041) or openbao's [PKI secrets engine](https://openbao.org/docs/secrets/pki/) (#87) - [ ] machine SSH keys ((`test-`)`machines/`) - see clan module `sshd` or openbao's [PKI secrets engine](https://openbao.org/docs/secrets/pki/)) - [ ] needed to facilitate contributions (#288) - [ ] name servers - make configurable (offering a default)? - [ ] users (developers, shared account) - see clan modules `root-password` / `user-password` - [ ] needed to streamline dev-ops (#224) - [ ] NixOS `system.stateVersion` - see clan module `state-version` - ~~#116: needed to automatically test proxmox~~ state scenarios: | destination | sensitive | storage | distribution | |---|---|---|---| | orchestration | * | openbao | nimbolus | | build | no | (depends on source) | build | | system | no | on-machine | vars | | system | yes | on-machine (vars) -> openbao | vars -> openbao? | | service | no | on-machine | (nix-templating +) vars | | service | yes | on-machine (vars) -> openbao | (nix-templating +) vars -> systemd-openbao | | destination | unsensitive | sensitive | |-|-|-| | orchestration | TF state | TF state | | build | | n/a | | system | vars | openbao? | | service (nix-templating +) | vars | systemd-openbao | | info | sensitive | destination | source | goal | |-|-|-|-|-| | MAC address | no | build | provisioning | #116 provisioning | | IP address | no | build | provisioning | #116 provisioning | | architecture | no | build | provisioning | #116 provisioning | | gateway | no | build | provisioning | #116 provisioning | | hardware | no? | build | `nixos-facter` | #116 provisioning | | authorized SSH keys | no | system | config: host | #116 provisioning | | TLS/SSL certificates | yes | service | bao PKI | #116 provisioning | | SSH keys | yes | system | bao PKI / vars `sshd` | #291 security | | service credentials | yes | service | vars? | #291 security | | `system.stateVersion` | no | build | vars `state-version` | #224 devops | | name servers | no | build | config: operator | #288 contributions | | user credentials | yes | build? | vars `{root,user}-password` | #288 contributions |

kiara commented

2025-04-19 13:08:45 +02:00

Author

Owner

clan's vars (+ templating) may help generate these, and supports different back-ends (could be used with openbao / even TF state?).

clan further implemented clanModules (since replaced) using this like:

general
- state-version (might decrease reproducibility, given this changes the behavior of a machine based on whether they were initialized before or after a stable update)
- machine-id (if LXC containers don't need this then great?)
- disk-id (no new equivalent)
- root-password (no new equivalent)
- user-password (new users seems less clean)
service-specific
- sshd (going by minimum privilege, should we even use this?)
- garage

edit: (untested) ~~attempt~~ PR to decouple those modules from clan using vars

mrVanDalo/clan-vars-generators contains:

matrix-synapse
nix-serve
openssh
syncthing
tinc
tor
wireguard
xkcdpass
zfs

clan's [vars](https://clan.lol/blog/vars/) (+ [templating](https://github.com/Lassulus/nix-templating)) may help generate these, and supports different [back-ends](https://docs.clan.lol/manual/vars-backend/) (could be used with openbao / even TF state?). clan further implemented [`clanModules`](https://docs.clan.lol/reference/clanModules/) (since [replaced](https://clan.lol/docs/25.11/guides/migrations/migrate-inventory-services)) using this like: - general - [`state-version`](https://clan.lol/docs/25.11/reference/clan.core/settings#state-version) (might decrease reproducibility, given this changes the behavior of a machine based on whether they were initialized before or after a stable update) - [`machine-id`](https://clan.lol/docs/25.11/reference/clan.core/settings#machine-id) (if LXC containers don't need this then great?) - `disk-id` (no new equivalent) - `root-password` (no new equivalent) - `user-password` (new `users` seems less clean) - service-specific - [`sshd`](https://clan.lol/docs/25.11/services/official/sshd) (going by minimum privilege, should we even use this?) - [`garage`](https://clan.lol/docs/25.11/services/official/garage) edit: (untested) ~~[attempt](https://git.clan.lol/clan/clan-core/compare/main...kiara/clan-core:decouple-ephemeral)~~ [PR](https://github.com/Lassulus/vars/pull/12) to decouple those modules from clan using [vars](https://github.com/Lassulus/vars) `mrVanDalo/clan-vars-generators` [contains](https://github.com/mrVanDalo/clan-vars-generators/tree/main/lib/generators): - `matrix-synapse` - `nix-serve` - `openssh` - `syncthing` - `tinc` - `tor` - `wireguard` - `xkcdpass` - `zfs`

Rows
Columns