Could someone who uses the NixOps EC2 backend please confirm my belief that the EC2 backend persists AWS access keys to the NixOps database? I don't use it, myself, but unless I missed something in the EC2 code, I don't see how it could behave otherwise.

Also, I want to go on record as saying that I don't think it's a very good idea to persist AWS access keys or DigitalOcean API tokens to the NixOps state database! But that's a decision for the NixOps team to make -- this change only intends to make the DigitalOcean backend behave like the EC2 one already does with respect to those keys/tokens.

I've added support for IPv6 in a separate commit, but the diffs overlap, so I'll wait until the authToken fix is accepted before submitting the IPv6 enhancement.

edit: ugh, looks like GitHub has automatically merged the IPv6 commit into the authToken commit. :\

I've edited the title of this PR to reflect that GitHub has merged the 2 commits. I'm happy to resubmit them one-by-one if that's preferable.

cc @teh

Thanks! I'm not 100% sure what to do here. ec2 stores the acces key but not the secret. And the DO token is both access key and secret rolled into one. I think I'd prefer to keep it out of the state file, but I also understand the argument for keeping it in.

@dhess what's your use case for carrying around the DO auth token in the state file?

As I mentioned above, I would prefer not to keep the token in the state file. I think it's a bad idea. But in this patch, I was only using the configuration mechanisms that NixOps supports out-of-the-box. Unless I'm missing something, once you set a property on a MachineState from the declarative configuration, it gets persisted to the state file.

You make a good point about how AWS separates the authentication into separate ID and key pieces, and that NixOps doesn't persist the AWS key in the NixOps database. That is because the key never needs to be set in the NixOps declarative configuration, only the ID. Luckily boto or whatever will handle loading the key for you, given just the ID. I hadn't considered that wrinkle. Unfortunately, the DigitalOcean Python module does not support loading a key from a .credentials file or similar; nor does the DigitalOcean API separate the two concepts of key and ID, as you pointed out.

Anyway, here is how I think the DigitalOcean backend should work: you set the digitalOcean.authToken in your declarative deployment configuration. You can set its value inline, if you choose; or you can use builtins.readFile to read the token from a file that you keep in an encrypted store (this is what I do). The DigitalOcean backend evaluates digitalOcean.authToken from the declarative configuration every time it performs an operation on a DigitalOcean target, and it never persists the value of this variable to the state file.

Unfortunately, I did not see any examples of this behavior in the existing backends. There appears to be no way to set a backend property with attr_property that is not persisted to the state database.

Is there were a way to create a property that is always loaded from the declarative configuration and never stored in the database? If not, it would be useful for cases like this.

At any rate, now that you've pointed out that the EC2 backend does not persist your EC2 secret to the state database, I think this patch is probably a bad idea and I am going to close it, unless someone objects.

OK, I'm closing this PR. It's a bad idea. Better to wait for a proper fix than to dump DigitalOcean auth tokens into the NixOps state database.

Is there were a way to create a property that is always loaded from the declarative configuration and never stored in the database? If not, it would be useful for cases like this.

I can't see anything obvious but then I'm struggling a bit with nixops internals :/

Thanks for doing the work in any case!