feat: add amneziawg extension

[masterbpro]

No description provided.

[smira]

I don't see where the shell is coming from? It should inside the container rootfs for the script to work

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[gentoosys]

Hi @masterbpro — thanks for getting amneziawg support moving, this is genuinely useful for clusters that span networks where plain WireGuard gets DPI-fingerprinted.

I hit the exact thing @smira flagged in review (the entrypoint.sh needs a shell inside the container rootfs). Rather than add bash + iproute2 to the extension's rootfs, I went the other way and replaced awg-quick with a small Go helper — which matches the precedent the other network/ extensions already set (tailscale, nebula, netbird, zerotier all ship a Go binary entrypoint, no shell).

I've been running it in production for a few weeks on a two-node control plane split across two datacenters on different continents (~140 ms RTT) — awg0 comes up at boot before etcd/kubelet, and etcd peering, kube-apiserver, kubelet and Cilium pod-to-pod (native routing) all flow over the mesh.

Sources here, with unit tests: https://github.com/gentoosys/talos-awg-up

What it does (the subset of awg-quick an extension service actually needs):

• ip link add awg0 type amneziawg, address, MTU, up — via vishvananda/netlink, no iproute2
• parses the wg-quick-style .conf, strips the wg-quick-only fields, and pipes the rest to awg setconf (the obfuscation fields Jc/Jmin/Jmax/S1/S2/H1..H4 go through awg since wgctrl doesn't speak them)
• installs a route per AllowedIPs prefix; idempotent across restarts

The win is the service container becomes scratch + awg (~50 KB C binary) + the Go helper (~2.6 MB static) — no shell, and notably no /proc mount. awg-quick needs /proc because its process-substitution (awg setconf <(...)) resolves /dev/fd/63 → /proc/self/fd/63; making that work inside a sandboxed extension service container otherwise means bind-mounting host /proc (exposes the host process table) or a fresh-procfs mount. The Go path sidesteps that entirely.

Happy to contribute this whichever way is least disruptive — fold it into this PR, or open a follow-up once this lands. I'm also preparing a full extension PR (the pkg.yaml + service definition wired to the Go helper, plus the companion siderolabs/pkgs PR for the signed kernel module). Glad to coordinate so we're not duplicating effort — your call on ordering.

[gentoosys]

Followed up on my comment above — I've opened the kernel-module version as a draft pair so there's something concrete to compare against:

• feat: add amneziawg extension (kernel module, shell-free Go helper) #1103 — network/amneziawg extension (shell-free awg-up Go helper)
• feat: add amneziawg kernel module + awg userspace package pkgs#1571 — amneziawg-pkg (signed .ko + static awg)

To be clear, I don't think this is strictly "better" than your #1004 — it's a different trade-off, and they're complementary:

• feat: add amneziawg extension #1004 (userspace amneziawg-go) wins on maintenance: kernel-independent, no per-kernel-bump rebuild, no module signing, single self-contained PR.
• feat: add amneziawg extension (kernel module, shell-free Go helper) #1103 (kernel module) wins on datapath: native kernel WireGuard path (no userspace TUN copy) — lower latency/CPU, higher throughput, which matters when the mesh carries etcd + pod traffic. Cost is the per-kernel .ko rebuild + the companion pkgs PR.

Both also drop the bash dependency @smira flagged — #1103 via the Go helper.

No interest in stepping on your PR — you got here first and the userspace approach is genuinely the lower-maintenance option. Posting the kernel-module variant mainly so maintainers can see both and decide whether they want one canonical extension or both as options. Glad to consolidate / co-author whichever direction the team prefers.