wireguard "wire-up"

[blaggacao]

Would your feature fix an existing issue?

Setting up site-to-site networking is hard.

Describe the solution you'd like

A wireguard wire-up (in the accustomed well-though-through devos way) would make things a lot easier. It might be even conceivable that all hosts within a devos repository are wired-up by default and are immediately (even remotely) reachable over the wg interface and a pre-configured IP.

Describe alternatives you've considered

zerotier

Additional context

• https://christine.website/blog/my-wireguard-setup-2021-02-06

• In addition to wiring up one's own devos environment, this should also be helpful if anybody needs to contract help from the (devos) community for one of their environments. (like me contracting with somebody to help me with some harder things I'm hardly able to complete in due time on my own 😉).

  • Such scenario could relatively cleanly be covered with documentation and maybe a configuration option which gives a consultant access to the all hosts under their wg IP address. (w/o handling of address conflicts, that might be a whole other beast)

/cc @Xe Do I trigger any (faint) impetus with you to further the devos cause through this Issue?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Pacman99]

This would be really cool! I think one change in devos overall that could help is to add a specialArg that gives access to every other hosts configuration. Then we could add a module for wireguard that will generate the relevant configurations for each host.

[nrdxp]

I was already planning on stealing the hosts.toml idea from this blog post. I was figuring that we could use it to setup deploy-rs nodes automagically, adding in the wireguard bits seem pretty awesome as well.

[Pacman99]

Whats the point in adding a hosts.toml? Wouldn't it be better to use the module system to get information about each host? And if you need more information, you could just add some options.

[nrdxp]

Now I see where you are going @Pacman99, your right, it may be better to pull the information directly from the other configs, to ensure information never goes stale. I was primarily like the toml for easily declaration of IP's though, perhaps a NixOS module option that stores the system's current IP wouldn't be a bad idea.

[blaggacao]

I also think hosts.toml can be rather an afterthought. This also goes alltogether into the direction of host identity. In private repository I bootstrap hostidentity with spire/spiffe and also put the host onto the LDAP record (for a few other things such as nss-pam over the network). My reduced yaml config file looks like this for reference (of ideas what can comprise a host identity, cn, dns, mac [for netboot and such] ):

entries:
- spiffe_id: spiffe://playground/agents # alias for all spire agents in this cluster
  parent_id: spiffe://playground/spire/server
  selectors:
  - type: k8s_psat
    value: cluster:playground
  - type: k8s_psat
    value: agent_ns:spire
  - type: k8s_psat
    value: agent_sa:spire-agent
- spiffe_id: spiffe://playground/nodes/k8s/oso-1
  # When generating the join token, use this as predictable node alias
  parent_id: spiffe://playground/nodes/k8s/oso-1/tokenalias
  dns_names:
  # CN of SubjectName matched by SASL/EXTERNAL for LDAP AuthC
  - oso-1.k8s.nodes.playground
  selectors:
  - type: unix # for aedir to work, aehostd identifies as the host it runs on
    value: name:aehostd
    # - type: unix
    #   value: path:/nix/store/a0avxqggj4rz791qq9rb4xjm196dj035-aehostd/bin/aehostd
    # - type: unix
    #   value: sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7
  # ---------------------------------------------
  # AE-Dir relevant attributes - ignored by spire
  # ---------------------------------------------
  aedir:
    dn: host=oso-1.k8s.nodes.playground,cn=playground-k8s-nodes,cn=playground,ou=ae-dir
    aeLocation: cn=BOG-playground,cn=people,ou=ae-dir
    aeOwner: uniqueIdentifier=jodo,cn=people,ou=ae-dir
    ipHostNumber: 172.0.11.1
    aeHwSerialNumber: SERIAL123
    aeStockId: STOCKID-675
    cn: oso-1.k8s.nodes.playground
    host: oso-1.k8s.nodes.playground
  # ---------------------------------------------

[Xe]

To be fair, I did the hosts.toml thing because it was a minimal viable solution to my problem.

[nrdxp]

Perhaps yggdrasil would also be helpful here

[blaggacao]

Checked in on the research list. I read "self-arranging" with eager.