We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

We should manage secrets the systemd way!

00:00

Formal Metadata

Title
We should manage secrets the systemd way!
Title of Series
Number of Parts
28
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Systemd 250 introduced a way to manage encrypted "credentials" (secrets, really) in a way that I think NixOS could benefit from. We're not using it anywhere yet, but we should. This describes briefly how systemd wants to manage credentials and how to integrate that in a NixOS setup.
PasswordProxy serverData managementSound effectOpen sourceExecution unitSoftwareOperating systemQuicksortSource codeWeb pageProduct (business)WikiRevision controlData storage deviceDifferential equationProof theoryBuildingPhysical systemPublic-key cryptographyPattern languagePasswordInformationDirectory serviceComputer configurationTouchscreenOnline helpScripting language
Transcript: English(auto-generated)
Hi everybody, I'm Ariel. Let me tell you a story about how I started using Nix OS. My friends were like, hey, this is great, it's reproducible, declarative and everything. So I'm like, cool, I'll create a VM and I'll create a user on that VM so I can play around and it's declarative, so I'll set a password for that user declaratively, should be easy, right? So the very first option I looked up was how do you set a password for a user?
User's username password, like pretty easy, right? Oh wait, the help says don't use that because it's terribly insecure. Turns out Nix is not great with secrets because Nix is a package manager and package managers don't typically carry secrets around. They build, especially for Nix, mostly open source software.
So it really wants to put all the source and all the products in the store and the store is world readable. But Nix OS is an operating system and operating systems do need some secret management. Like you have stuff in Etsy or in your home directory if you're using home manager, like that stuff, you don't want everybody to read it or at least not in clear text.
So I wasn't super impressed by this first experience. So the next thing I did was look up, well, how do people manage secrets in there? Because it's a problem we've all faced or like many of us have faced, this is a fertile ground for invention. There's this Wiki page
that's completely unreadable on the screen that's kind of unavoidable. It has eight entries. They're all actually very interesting and good, but basically what they all do is they say, well, secrets should be managed outside of Nix. Like we'll just hook in either in like some system, the units, or we'll put that in the activation script
or like completely outside of all that, but just don't put it in Nix. And that works, but it has one small problem, which is everybody's doing different things and not in Nix. And that means that Nixos modules aren't really designed to work with secrets managed that way.
And the second order effect of that is that this is making the easy thing dangerous and the right thing hard. Like if you do want to set your user's password, you're probably gonna use that option. It's very attractive. And if you have a multi-user system, you're doing something really wrong that way.
So we need to do something where what is right is easy. Otherwise as an OS, we're probably going to set ourselves up for a big failure. So we're building on systemd. And it turns out systemd has systemd credentials management. It's pretty easy to use, honestly. I mean, the command lines are scary,
but that's just like systemd in general. Very quickly, what it does is it encrypts a secret to a per host key. If you have a TPM, it uses that to back that key. And nice bonus, it manages your secrets, ownership and permissions for you because it only makes them available to the units that you wanted there,
which is kind of nice when you use other solutions in the Wiki page. Many of them you have to manage permissions by hand. It's a little complicated. This actually is sort of used in Nixos. There was this issue that discussed, can we use that for secrets? And we closed it successfully saying, yes, we can use that, but then we never actually used it.
It never is like, it's not true. We used it in about 15 modules, but only for the unencrypted version where the secret is still in clear text. So it doesn't quite work, but I have a proof of concept in creating with Aginix, which is one of the eight entries in the Wiki that encrypts to the per host key.
So where can we go from there? Well, good patterns I think in Nixos tend to emerge from people doing something, recognizing it's successful and copying from each other and just kind of evolving or likely, and then it gets standardized. So I'd love to talk to people during the hack day about, hey, how would you like to use this in your system?
Can we try some approaches? Can we hack on some tooling and see what works for you? And then once that works, we can drive some adoption. Also, I saw somebody with a system D t-shirt yesterday. I'd love to talk to you because there is one small to-do about asymmetric encryption for this in system D. And that would make things so much easier.
So come talk to me if you're interested in any of that. I'll probably be behind the bar most of today, and this is my contact info. Thank you.