digga
digga copied to clipboard
wireguard "wire-up"
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 :wink:).- 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.
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.
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.
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.
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.
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
# ---------------------------------------------
To be fair, I did the hosts.toml thing because it was a minimal viable solution to my problem.
Perhaps yggdrasil would also be helpful here
Checked in on the research list. I read "self-arranging" with eager.