0

What are the best practices for managing account credentials and SHA256 secrets and providing them to systemd managed services?

In the old init.d way, I'd just install a script in /etc/default that gets sourced. From there I could import whatever content I want into environment variables which are then available to my services.

So my question is, what is considered "best practice" for providing logind id/password credentials and other "secrets" to systemd managed services? Is passing it via the environment considered "good" or is there an accepted better/more secure way?

(i.e. what is the best place to put your service (e.g. mysql) passwords, SHA256 secrets, etc and how do you most effectively communicate those to long running background services that need it? Is there a better managed way than setting them in the environment before processes are launched by systemd?)

Yermo Lamers
  • 111
  • 6
  • If you want to modify the environment why not use `EnvironmentFile`? Something like `EnvironmentFile=-/usr/local/sbin/loadenv` perhaps? – Zoredache Jul 10 '17 at 19:52
  • 1
    BTW, it isn't clear to me what kind of credentials/secrets you are trying to pass, or why you would need to do it via the environment. All the details you provided was about systemd. – Zoredache Jul 10 '17 at 19:55
  • 1
    I have no idea what you're trying to achieve. Can you edit your question to clarify? What secrets are you talking about? – Tim Jul 10 '17 at 20:04
  • @Tim For example an SHA256 hash secret used to validate javascript web tokens that might need to be shared between an oauth server and some web service. How do you communicate that to services that need it? In the "old way" you'd just run a script from /etc/default/xyzservice where you could pull in the secret from some central secure place and put it in an environment variable of the service. The same is done with passwords and other credentials. – Yermo Lamers Jul 11 '17 at 01:18

1 Answers1

2

I don't there's one right way to pass secure credentials with systemd. The Environment= and EnvironmentFile= directives are definitely there to help pass environment variables, similar to older init systems. If you are looking for a direct translation of what you used to do, that's it.

Your app might also use it's own config system like node-config for Node.js. The config package may then in turn provide further alternatives for managing secrets. As an example, node-config can also load values from environment variables, but it's also possible to work git-crypt, to work with values that have been stored encrypted in Git.

Some things to be aware of with environment variables: Even if you don't keep the environment variables you set in a file, if you pass them to a process when it's started up, the environment variables and their values may be found in file names like /proc/27/environ on Linux, for users to have permissions to read the file. These "start up environment" values persist there even if the process later deletes them.

If you do load environment variables into an apps configuration system, considering having the process delete the environment variables from process once they are in the configuration system. Then at least if you have the sensitive information in one less place.

Mark Stosberg
  • 3,901
  • 24
  • 28