Open ixxie opened 6 years ago
There are only two key choices: You store it on the machine to require no user input, or you don't.
Any form of encryption that doesn't require user input is almost analogous to clear text; an attacker obtaining access to the machine will be able to unlock it without user input.
If you require user input, you might as well just require the credential itself as input.
The way it's common with AWS is that your credentials are stored in clear text in ~/.aws/credentials
. Such a scheme is always better than putting your clear text credentials into your .nix
file because it allows you to check in the .nix
file into the repo (no credentials in source repositories), and to chown 600
the credentials file so that only your user can see it.
You can do things like deployment.digitalOcean.authToken = builtins.readFile ...
to implement that scheme for DigitalOcean.
But I doubt that NixOps itself can provide a better story for "storing" these keys than you can yourself.
Does that make sense?
@nh2 makes a lot of sense; I guess a nice compromise between security and convenience would be to encrypt all the keys for NixOps using one password; a password is certainly easier to memorize than an authentication key!
I imagine it would be difficult to implement as a feature, but reasonable to implement for a personal configuration, by - for example - encrypting a /secrets
folder. I guess the tricky bit is finding a convenient way to 'wrap' the nixops
CLI with the decryption logic.
@ixxie I think the way I would do that is to wrap nixops that can fetch your password by running a command, and store it in an environment variable like DIGITAL_OCEAN_AUTH_TOKEN
for the nixops invocation.
For example, for Hetzner I use (roughly) this bash script to wrap nixops to prompt me for my Hetzner password:
read -p 'Enter Hetzner subaccount password: ' -s password && echo && HETZNER_ROBOT_PASS="$password" nixops $@
That way you can externalise the password storage and make it the responsibility of another program, for example, you could
pass
or gpg
@nh2 - sounds good; once I will figure out how to fix https://github.com/NixOS/nixops/issues/945 and get my NixOps deployment ready, I will try this out and hopefully also document the whole think in the NixOS Wiki (which so far is a bit low on NixOps contributions).
Quoting the Digital Ocean chapter of the NixOps manual on how to store the authentication token for the Digital Ocean backend:
I am no security guru, but this strikes me as a little insecure? I am wondering how to persist the environment variable or configuration option in a more secure way; are there best practices or tools that allow me to avoid having to store my authentication token in the clear?