Secure Persistant Storage of Digital Ocean Auth Keys

[ixxie]

Quoting the Digital Ocean chapter of the NixOps manual on how to store the authentication token for the Digital Ocean backend:

[..] have the DIGITAL_OCEAN_AUTH_TOKEN set with an authentication token, obtained from the Digital Ocean console. The token can also be provided via the deployment.digitalOcean.authToken option.

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?

[nh2]

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?

[ixxie]

@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.

[nh2]

@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

• invoke pass or gpg
• contact Vault
• invoke some other password storage program

[ixxie]

@nh2 - sounds good; once I will figure out how to fix #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).