# nix vars talk @planet-nix - talk slides: https://pad.lassul.us/6_81SmXlReSvGSXeepKl-Q?both - we want to integrate with projects like sops-nix, agenix Possibly other backends in the future -> openbao, etc. ### part 0: Current Implementations in the wild Show current key generation scripts that are basically half of what vars are now, they generate the keys on service start. But Hard to manage state. ``` services.openssh.hostKeys ``` or ``` servics.syncthing.enable ``` Issues with this approach: Generation part of booting the system. Module maintainers need to care about the secure generation, not just of how they are generated and used securely. ### part 1: example problems: - stateVersion - user passwords - ssh keys - testing of services? A form of secret (state) management with low footprint, but large impact. ### part 1.5 (or somewhere else)?: Comparison of Different Tooling Solutions - Only nixpkgs - Nixpkgs + sops-nix - Nixpkgs + sops-nix + vars Here we can use a graphic that fits vars into it like a puzzle piece. ### part 2: solution: - explain generators - dependencies - runtimeInputs - dependencies Complexity shifts: - from users to module authors of how to generate passwords - bootstrapping services is easier - from module authors to backend authors of how to generate securely - module authors don't need to reimplement the same logic multiple times - problems with secure generation can be managed by a specific backend designed for it ### part 3: example implementation - explain the on-machine example implementation - show a bit of clan implementation ### part 4: future of vars - talk about RFC - link to PR ### extra stuff - lessons learned from earlier implementation - tradeoffs: - An extra backend means possibly more complexity - Not every service is compatible with such a system - why not machines that have no secrets and use only TPM? - problems that now come to light -> restarting of secrets, because we have easier secret rotation now ### TODO: Bootstrapping Secrets in general -> Default passwords Any explicit password setting is now incompatible with the generation. Through the: ``` systemd.services.sshd.preStart ``` for example. ### Paradigm Shift Find a good example and play it through line by line? #### In Store Configuration gets Secrets. Secrets in store -> world readable Clearly not a viable solution. #### Path in Store Configuration gets Path to Secrets. `/run/path-to-secrets` Better solution, but that brings new problems: - Need to deploy secrets to target system #### Add `agenix` / `sops-nix` Is responsible for managing the path to the secret, the encryption / decryption But: Secret still needs to be handled manually and generated out of band, with tools available directly for the user generating them. #### Add `vars` Can handle secret generation. Can integrate with existing secret deployment solutions (doesn't need to reinvent the wheel). #### Secrets Are Special Kind of State Secrets are a kind of state that should be manageable and with var's it is. Secrets (State) initializes machines + Configuration -> Running Machine -> Creates State #### Vars: The Missing Puzzlepiece for Secret Generation