Every node is uniquely identified on VL1 by a 40-bit (10 hex digit) ZeroTier address.
This address is computed from the public portion of a public/private key pair. A node’s address, public key, and private key together form its identity.
On devices running ZeroTier One the node identity is stored in identity.public and identity.secret in the service’s home directory.
When ZeroTier starts for the first time it generates a new identity. It then attempts to advertise it upstream to the network. In the very unlikely event that the identity’s 40-bit unique address is taken, it discards it and generates another."
Technically it should be possible to modify the module. The two files would have to be copied or linked from the nix store into the home directory before the start of the service, similar to what’s already being done here.
The downside is that the identity.secret would be in the nix store with world-readable permissions, which isn’t ideal for something that’s supposed to be secret.
I see. I guess this is a problem not unique to ZeroTier. Is there a standard solution? Am I making a fundamental mistake in trying to declaratively specify a secret for a machine (when no-one except me has access to the machine or to the specification)?
Anything that is built by the nix daemon ends up world readable. I believe there is a github issue open for that with some suggestions, but as far as I understand, nothing that will be ready soon.
There are basically two ways to get around this:
Let the system generate the secret itself (let’s encrypt certificates are a good example for this).
Inject the secret through different means, for example a script that creates /var/lib/mysecrets and copies the necessary files. Nixops is doing pretty much exactly that, with the option that the keys are only stored in RAM (requires a redploy after reboot) or on disk (allows unattended reboots).
What you choose depends a lot on your intentions