Add documentation on using cloud-init's wireguard feature#105
Add documentation on using cloud-init's wireguard feature#105davidallendj wants to merge 1 commit into
Conversation
Signed-off-by: David Allen <davidallendj@gmail.com>
davidallendj
force-pushed
the
allend/add-wireguard-docs
branch
from
23ae5b1 to
c17439f
Compare
davidallendj
changed the title
seantrons
left a comment
seantrons
left a comment
There was a problem hiding this comment.
Looks good, mostly small nitpicks on my side about ensuring we tell the full story. Otherwise excellent!
| {{< callout context="note" title="Important" icon="info-circle" >}} | ||
| The `/cloud-init/wg-init` and `/cloud-init/phone-home/{id}` endpoints are **never** restricted by the WireGuard middleware, even when `WIREGUARD_ONLY=true`. This allows nodes to establish their WireGuard tunnel before fetching cloud-init data. | ||
| {{< /callout >}} |
There was a problem hiding this comment.
If you want to be pedantic, all routes matching /cloud-init/admin/* (all admin routes) also do not need wireguard even when this flag is true.
| ```text | ||
| ┌──────────────┐ WireGuard Tunnel ┌──────────────────┐ | ||
| │ Compute │ ◄────────────────────────► │ cloud-init │ | ||
| │ Node │ wg0: 100.97.0.x/32 │ Server │ | ||
| │ │ │ wg0: 100.97.0.1 │ | ||
| └──────────────┘ └──────────────────┘ | ||
| │ │ | ||
| │ 1. POST /cloud-init/wg-init │ | ||
| │ (before cloud-init starts) │ | ||
| │ │ | ||
| │ 2. GET /meta-data, /vendor-data │ | ||
| │ (over WireGuard tunnel) │ | ||
| └───────────────────────────────────────────┘ | ||
| ``` |
There was a problem hiding this comment.
Malformed graph chars (e.g., pipe | symbols not aligned)
| OpenCHAMI's cloud-init server supports **WireGuard** to encrypt and isolate cloud-init traffic between compute nodes and the cloud-init server. This ensures that sensitive metadata, user data, and vendor data exchanged during node provisioning are transmitted over an encrypted tunnel. | ||
|
|
||
| The cloud-init server embeds a WireGuard server that dynamically assigns VPN IPs to compute nodes, manages peer configurations, and can optionally restrict cloud-init data access to only those nodes connected via the WireGuard tunnel. | ||
|
|
There was a problem hiding this comment.
Might want to add some detail here:
For instance, my biggest item of confusion was "why wireguard when we already have TLS for http communications?"
Note
I talked with travis about this and the primary reason is:
- TLS doesn't protect against smart users. Smart users could technically
curlthe API endpoints and obtain any secrets delivered by the cloud-init-server.
|
|
||
| ```ini | ||
| # /etc/containers/systemd/cloud-init-server.container.d/10-override.conf | ||
| [Container] | ||
| Image=ghcr.io/openchami/cloud-init:v1.4.2 | ||
| Environment=WIREGUARD_SERVER=172.16.1.1/24 | ||
| Environment=WIREGUARD_ONLY=true | ||
| Environment=DEBUG=true | ||
| AddCapability=NET_ADMIN | ||
| AddDevice=/dev/net/tun | ||
| PublishPort=58036:58036/udp | ||
| Network=openchami-internal.network:alias=cloud-init-int | ||
| Network=openchami-external.network:alias=cloud-init-wg | ||
| ``` | ||
|
|
There was a problem hiding this comment.
IIRC, this is fine. Otherwise it might be adding a dependencies on OpenCHAMI/release#61
| ```haproxy | ||
| backend cloud-init | ||
| server cloud-init-server cloud-init-int:27777 | ||
| ``` |
There was a problem hiding this comment.
Versions of cloud-init-server >= v1.3.0 do actually need the http url rewriting line that was below this one.
Sorry, this one's completely on me. I left it in there because the majority of my testing was for v1.2.3.
|
|
||
| {{< details "Example ochami-ci-setup.sh" >}} | ||
|
|
||
| ```bash | ||
| #!/bin/sh | ||
| set -e -o pipefail | ||
|
|
||
| if [ -z "${ochami_wg_ip}" ]; then |
There was a problem hiding this comment.
The path here doesn't line up with the image builder path below.
| ```yaml | ||
| packages: | ||
| - wireguard-tools | ||
| ``` |
There was a problem hiding this comment.
optional nitpick:
wireguard-tools -> rhel
wireguard -> debian
|
|
||
| # Verify the tunnel is resolving the cloud-init server | ||
| ping 100.97.0.1 | ||
| ``` |
There was a problem hiding this comment.
the wg0 interface is supposed to delete itself per the override.conf file, otherwise this presents a security vulnerability as unprivileged users will be able to query the cloud-init api and steal secrets.
So it might be better to phrase this w.r.t. a debug image. For instance, when debugging, I'd use a debug layer on top of the image builder layer I was targeting so I could log in with a testuser.
Then I could run commands like this and if successful, they should both work.
However, if the script was failing out in terms of getting the wireguard interface up, then I could go to the install location (/usr/local/bin in this case, set the ochami_wg_ip, do a set -x and run the script manually to get a better idea of what was going wrong.
| ```bash | ||
| # List WireGuard peers | ||
| wg show wg0 | ||
|
|
There was a problem hiding this comment.
might want to mention this first CMD needs to be run within the cloud-init-server container's net_ns. an easy way to do it is just a simple sudo podman exec -it cloud-init-server wg show wg0
|
|
||
| ```text | ||
| Access denied: IP 10.89.2.63 not in WireGuard subnet or interface | ||
| ``` |
There was a problem hiding this comment.
So right idea but the address listed can be misleading. This is the address from the bug and occurs when querying from the reverse proxy. After the bug fix, this should only show the IP4 of the peers external facing interface (regular one, not the wireguard interface).
2 participants
Pull Request Template
Thank you for your contribution! Please ensure the following before submitting:
Checklist
make test(or equivalent) locally and all tests passgit commit -s) with my real name and email<filename>.licensesidecarLICENSES/directoryDescription
This PR adds info about using the wireguard feature in cloud-init under
/docs/software/cloud-init/wireguard.Type of Change
For more info, see Contributing Guidelines.