Using SOPS to hide the ip-address of the server in public repository?

Help
1

Hey,

I would want to share my machine configuration openly in github but without publishing the ipv6 address of the server.

systemd.network.networks."10-uplink".networkConfig.Address = "XXXX:YYY:ZZZZ:WWWW::2/64";

Is there a way how I could read this value from SOPS?

I think the srvos configs I’m using make it mandatory since I get this error when I leave it away:

error:
       Failed assertions:
       - The machine IPv6 address must be set to
       `systemd.network.networks."10-uplink".networkConfig.Address`
2

No. Sops secrets are not available during eval. This is not intended to work. It comes up quite regularly.

What you could do is written here: Sops failing to start - #31 by dtannock

You can read the whole thread if you want to know why this does not work.

3

I’m using this overlay: nur-packages/overlays/extra-builtins at a5d9f494d382314cfddd278d22af9d39a3fb1f19 · dguibert/nur-packages · GitHub
the function is sopsDecrypt $sopsFile $key.

This used to work with extra-builtins plugin (not tested for a while).
But it can also be used with this option --option allow-unsafe-native-code-during-evaluation true that needs to be passed to nix, nixos-rebuild or deploy allowing the secrets to be available during eval. Keep in mind that despite not being available openly available in github it will end up clearly in your nix store.

4

If you don’t want to share a part of your configuration… just don’t do it.
You can place IP addresses, user names, etc. in a separate .nix file and add it to the .gitignore, or use git-crypt to encrypt that file (if you’re not using flakes).

2 Likes
5

Well this is very cumbersome to hear :sweat_smile:.

I don’t think there’s any upside of sharing this value to the internet in my case. It will just open the server for potential DDOS or worse.

I can at least read it from env instead:

systemd.network.networks."10-uplink".networkConfig.Address = builtins.getEnv "RUSTY_IPV6";
6

If git cript is so convenient and simple why is everyone building complex setups with sops and agenix?

7

One reason would be that git-crypt is fundamentally not secure with flakes. Since secrets sit in plaintext in the Git repo once git-crypt is unlocked, they will get copied into the Nix store as part of evaluation.

3 Likes
8

Thanks for all great answers so far. I was not aware of the plaintext secrets in the nix store. I think this happens even with my env approach.

Is there a way to read this information from a file eg a sops file?

I tried to search examples from github but I understood there’s no “AddressFile” attribute available in networking.

9

I think good secret management starts with understanding the threat model which is not necessarily the same everywhere so you’re likely to find varying thoughts and opinions here.

I haven’t used git-crypt with my nix projects to avoid secrets going into the world readable nix store but I wouldn’t go as far as saying you should avoid it completely (so long as you’ve thought of the threat model).

I use sops-nix to keep secrets out of the nix store and also because other tools I use (outside of the nix ecosystem) support sops which makes things like key management (rotation etc.) “easier”. I don’t feel like that’s a complex setup but I suppose it could be.

I don’t know if you’re thinking about which project to use for secret management but if you are, why don’t you try them all and see what works for you? I’m sure you’ll find help here as you go.

1 Like
10

This is not the point. I can use whatever works but I do want to use cachix or flakehub caching with GitHub actions. If I do this I understood that the ipv6 address will leak into the caches which is not desirable outcome.

I’m wondering how I could use public caches without exposing this information.

11

networkd supports “drop-ins” in /run that you can just generate at runtime before systemd-networkd.service starts. This is how systemd-network-generator.service creates networks based on cmdline or systemd credentials. Something like this would probably work

  sops.secrets."address.conf" = {
    owner = "systemd-network";
    group = "systemd-network";
    path = "/run/systemd/network/10-uplink.network.d/address.conf";
  };

Where this secret contains something like:

[Network]
Address=XXXX:YYY:ZZZZ:WWWW::2/64

Not sure if sops-nix needs something to make sure the this gets placed before systemd-networkd.service starts.

2 Likes
12

I wasn’t replying to you.

13

You made a very good point there. One of the reasons why it is so hard to me to understand certain security practices is, probably, because I don’t have in mind the problem they are trying to prevent. The short lived token + refresh token is an example. I usually assume that, if the short token can be stolen, why not the refresh one? And I have to re-read the why’s over and over again.

I guess that certain folders are considered “safer” than others (tempfs, root accessible only, etc). In my fase what I’m looking for is a convenient and safe way to distribute my full configs to my personal computers, so all this “enterprise grade” solutions are probably overkill for me.
Not to mention that I don’t spin up servers by dozens, so a bit of interactivity providing a password in my case is probably preferably to have secrets exposed to a future hypothetical quantum computer. So maybe a combination of private repo + encryption there (to be more secure) is probably what I’m looking for

14

This is just partially true. It is about the unix file permissions on those folders that determine who can read them. Especially /nix/store is readable by everyone meaning any program can read everything in there and hence retrieve your secrets. So for me personally that would be a bit too high of a risk which is why I use sops-nix to store my secrets. It is not that hard to implement and gives me that additional security.