4 ms·
Another great security feature systemd provides is credential management[1], which allows you to expose credentials to an application in a more secure way than,
by jamesponddotco 1y ago
Another great security feature systemd provides is credential management[1], which allows you to expose credentials to an application in a more secure way than, say, an environment variable or a file in the filesystem.
When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature.
[1]: https://systemd.io/CREDENTIALS/ https://systemd.io/CREDENTIALS/
[2]: https://sr.ht/~jamesponddotco/credential-go/ https://sr.ht/~jamesponddotco/credential-go/
- TheDong 1y agoI see we've decided to take the path of nodejs and npm, where 2-liners deserve their own package. dir, err := os.Getenv("CREDENTIALS_DIRECTORY") cred, err := os.ReadFile(filepath.Join(dir, "name")) That's less complexity than left-pad. I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
- jamesponddotco 1y agoI was writing the same few lines for every project, so why not make it its own package? For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
- skydhash 1y agoEditor macros/snippets?
- jamesponddotco 1y agoDidn’t think of that ¯\_(ツ)_/¯
- TheDong 1y agoUse rust or typescript or something where it's socially acceptable to make small packages. That'll also let you avoid writing the `if err != nil { return fmt.Errorf("context string something: %w", err) }` boilerplate again and again too (since you can just write '.context("context")?' each time). If you're using Go, you're not supposed to build abstractions, small packages, or any sorta clever or good code. And be really careful using generics. If you want to write abstractions, you're supposed to use a different language. Those are the rules.
- c0balt 1y agoFor what it's worth this will not work properly, you have different environment variables for user and system units. Proper error handling and graceful fallback for these cases are probably worth a module here (though it could be a 10-20 liner instead too).
- TheDong 1y ago> you have different environment variables for user and system units Really? I thought the point of the environment variable was it was the same, and the directory it pointed to differed depending on the service type. I'd love a reference since at least for every systemd version I've used, you're wrong. > Proper error handling and graceful fallback That's application specific, so it can't really fit in a generic library well.
- c0balt 1y ago> I'd love a reference since at least for every systemd version I've used, you're wrong. I must've had it confused with StateDirectory[0]. Thank you for pointing my mistake out. That does make the library a bit less useful. [0]: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html https://www.freedesktop.org/software/systemd/man/latest/syst... Table 2
- TheDong 1y agoStateDirectory looks like it's also always the environment variable 'STATE_DIRECTORY', regardless whether it's a user or system unit, right? systemd-run -p StateDirectory=test -t sh -c 'echo $STATE_DIRECTORY' works fine with both `--system` and `--user`, so seems like that's the same too.
- Arnavion 1y agosystemd's method does not require the service process to have access to the original creds file, or even the filesystem that contains it. In fact the original credentials file might even be an encrypted file and the key (and/or hardware) to decrypt it does not need to be accessible to the service process.
- o11c 1y ago... how exactly does it prevent inheritance to forked children?