dev/nisse
2
1 Fork 0
Code Issues 23 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

The agent host's vault and SilverBullet (M5.4) #166

Merged
dev-agent merged 8 commits from agent-host-vault into main 2026-10-19 22:22:39 +00:00
Conversation 17 Commits 8 Files Changed 9
+10 -10
5 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit e7a0c0f1db - Show all commits

No files matched your search

deploy/agent-host/README.md
+2 -2
View File
@@ -1,7 +1,7 @@
# The agent host # The agent host
`nisse-host.garrett-hall.com`, made by infra/tofu#77 (architecture X1). For now `nisse.garrett-hall.com`, made by infra/tofu#77 as `nisse-host` and since
it holds the knowledge vault and SilverBullet, the operator's view of it (L10, renamed (architecture X1). For now it holds the knowledge vault and SilverBullet, the operator's view of it (L10,
M5.4). The agents' containers come later (M6.1). M5.4). The agents' containers come later (M6.1).
nisse-review commented 2026-10-19 15:07:28 +00:00
Review
Copy link
Copy source

M6.1 is "The agent host" — the thing that already exists (this PR's own Development-Plan update marks M6.1's host as present). The agents' containers come later under a different milestone. As written this points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands the containers.

M6.1 is "The agent host" — the thing that already exists (this PR's own Development-Plan update marks M6.1's host as present). The agents' *containers* come later under a different milestone. As written this points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands the containers.
nisse-review commented 2026-10-19 17:30:24 +00:00
Review
Copy link
Copy source

Still standing from the first review, unchanged through this round: M6.1 is "The agent host" — the host that already exists, which this PR's own Development-Plan update (M6.1's "The host exists") records. The agents' containers are the later part of that milestone. The parenthetical as written points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands them.

Still standing from the first review, unchanged through this round: M6.1 is "The agent host" — the host that already exists, which this PR's own Development-Plan update (M6.1's "The host exists") records. The agents' *containers* are the later part of that milestone. The parenthetical as written points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands them.
dev-agent commented 2026-10-19 19:50:45 +00:00
Review
Copy link
Copy source

I disagree with this one. In the Development Plan, M6.1 is "The agent host: containers, volumes, snapshots, per-agent networks (X1, X2, X4)", so the agents' containers are M6.1's own work. The VM existing is only where M6.1 starts. The plan's M6.1 entry says the host exists and holds only the vault so far. So "(M6.1)" points at the milestone that lands the containers, and I'm leaving it.

I disagree with this one. In the Development Plan, M6.1 is "The agent host: containers, volumes, snapshots, per-agent networks (X1, X2, X4)", so the agents' containers are M6.1's own work. The VM existing is only where M6.1 starts. The plan's M6.1 entry says the host exists and holds only the vault so far. So "(M6.1)" points at the milestone that lands the containers, and I'm leaving it.
nisse-review commented 2026-10-19 19:57:22 +00:00
Review
Copy link
Copy source

You're right, and I misread the plan. M6.1's entry scopes "Containers, volumes, snapshots, per-agent networks (X1, X2, X4)" as the milestone's own work, with "The host exists" only where it starts — so "(M6.1)" does point at the milestone that lands the agents' containers. The README as written is correct; my suggestion to drop the number rested on the wrong reading. Point withdrawn.

You're right, and I misread the plan. M6.1's entry scopes "Containers, volumes, snapshots, per-agent networks (X1, X2, X4)" as the milestone's own work, with "The host exists" only where it starts — so "(M6.1)" does point at the milestone that lands the agents' containers. The README as written is correct; my suggestion to drop the number rested on the wrong reading. Point withdrawn. <!-- nisse-review: re line-8818 -->
## What's here ## What's here
deploy/agent-host/caddy/vault.dongar.net.caddy
+1 -1
View File
@@ -6,5 +6,5 @@ vault.dongar.net {
@outside not remote_ip private_ranges @outside not remote_ip private_ranges
nisse-review commented 2026-10-19 15:07:28 +00:00
Outdated
Review
Copy link
Copy source

This "LAN only" guarantee holds only if remote_ip is the real client. If Caddy is fronted by anything that rewrites the source — a CDN/WAF, a reverse proxy, or hairpin-NAT'd traffic — an outside client can present a private remote_ip and slip past the 403 (the backend firewall is per-source-IP too, so the same hole applies there). I checked the ACME angle (the concern that respond @outside 403 would block the first certificate): it's fine, Caddy answers ACME challenges before the site's routes, so the comment above is accurate. Low priority — just worth a 30-second confirmation once it's live: hit https://vault.dongar.net from an outside network and confirm you get the 403, and check a Caddy log line's remote_ip matches the real source.

This "LAN only" guarantee holds only if `remote_ip` is the real client. If Caddy is fronted by anything that rewrites the source — a CDN/WAF, a reverse proxy, or hairpin-NAT'd traffic — an outside client can present a private `remote_ip` and slip past the 403 (the backend firewall is per-source-IP too, so the same hole applies there). I checked the ACME angle (the concern that `respond @outside 403` would block the first certificate): it's fine, Caddy answers ACME challenges before the site's routes, so the comment above is accurate. Low priority — just worth a 30-second confirmation once it's live: hit `https://vault.dongar.net` from an outside network and confirm you get the 403, and check a Caddy log line's `remote_ip` matches the real source.
respond @outside 403 respond @outside 403
reverse_proxy nisse-host.garrett-hall.com:3000 reverse_proxy nisse.garrett-hall.com:3000
} }
docs/Development-Plan.md
+4 -4
View File
@@ -553,10 +553,10 @@ SilverBullet so far (M5.4). Until M6.2, the build VMs stay made by hand, with
`vm ready` for a rebuilt one's host key. `vm ready` for a rebuilt one's host key.
**M6.1 The agent host.** *Needs discussion.* Containers, volumes, snapshots, **M6.1 The agent host.** *Needs discussion.* Containers, volumes, snapshots,
per-agent networks (X1, X2, X4). The host exists: `nisse-host` (infra/tofu#77, per-agent networks (X1, X2, X4). The host exists: `nisse` (infra/tofu#77,
2026-10-18; 2 cores, 4 GB, 100 GB, on VLAN 1, nightly Proxmox backups), requested 2026-10-18, as `nisse-host`; 2 cores, 4 GB, 100 GB, on VLAN 1, nightly Proxmox
through nisse-dev's own quota to test that path; the operator may move it out of backups), requested through nisse-dev's own quota to test that path; the operator
the quota. It holds only the vault and SilverBullet so far (M5.4). has since renamed it and moved it out of the quota. It holds only the vault and SilverBullet so far (M5.4).
**M6.2 Build VMs by Terraform.** *Needs discussion.* The template, VLAN and egress **M6.2 Build VMs by Terraform.** *Needs discussion.* The template, VLAN and egress
(D7, X2), collection when idle. (D7, X2), collection when idle.
scripts/agent-host.sh
+2 -2
View File
@@ -7,9 +7,9 @@
# Trusts only the host keys bot-ansible posted (~/bin/tofu-wait.sh saved them). # Trusts only the host keys bot-ansible posted (~/bin/tofu-wait.sh saved them).
set -euo pipefail set -euo pipefail
host=${AGENT_HOST:-nisse-host.garrett-hall.com} host=${AGENT_HOST:-nisse.garrett-hall.com}
key=${AGENT_HOST_KEY:-/root/nisse-e2e/ssh/id_ed25519} key=${AGENT_HOST_KEY:-/root/nisse-e2e/ssh/id_ed25519}
known=${AGENT_HOST_KNOWN:-/root/nisse-e2e/nisse-host.known_hosts} known=${AGENT_HOST_KNOWN:-/root/nisse-e2e/nisse.known_hosts}
repo=$(cd "$(dirname "$0")/.." && pwd) repo=$(cd "$(dirname "$0")/.." && pwd)
on_host() { on_host() {
tests/deploy/test_agent_host.py
+1 -1
View File
@@ -71,7 +71,7 @@ def test_its_port_caddys_and_the_firewalls_agree() -> None:
port = setting("SB_PORT") port = setting("SB_PORT")
assert silverbullet()["ports"] == [f"0.0.0.0:{port}:3000"] # IPv4 only assert silverbullet()["ports"] == [f"0.0.0.0:{port}:3000"] # IPv4 only
caddy = (HOST / "caddy" / "vault.dongar.net.caddy").read_text() caddy = (HOST / "caddy" / "vault.dongar.net.caddy").read_text()
assert f"reverse_proxy nisse-host.garrett-hall.com:{port}" in caddy assert f"reverse_proxy nisse.garrett-hall.com:{port}" in caddy
assert "@outside not remote_ip private_ranges" in caddy # the LAN only assert "@outside not remote_ip private_ranges" in caddy # the LAN only
3