coilyco-flight-deck/infrastructure
1
0
Fork 0
Code Issues 101 Pull requests Projects Releases Packages Wiki Activity Actions 1

Treat LAN as semi-hostile: inventory + bind services to tailnet/loopback #110

New issue
Open
opened 2026-05-24 21:45:52 +00:00 by coilysiren · 0 comments
coilysiren commented 2026-05-24 21:45:52 +00:00
Owner
Copy link

Problem

Today the LAN is implicitly treated as a trust boundary - devices on the home network can reach each other and reach kai-server's LAN-side surface without per-flow authentication. That's the conventional home posture but it's wrong for Kai's actual threat model: a router compromise, an IoT device compromise, or a guest-device compromise all become full LAN access.

Goal

Move from 'LAN = trust boundary' to 'LAN = routing boundary, tailnet = trust boundary.' kai-server already does this for SSH (tailnet-only); extend the pattern.

Scope - in

  1. Inventory every service on every coilysiren-owned host that currently listens on the LAN interface. Build the list before changing anything.
  2. For each service, decide: (a) tailnet-only, (b) loopback + tailnet, or (c) genuinely needs LAN exposure (printers, Chromecast-style devices).
  3. Bind LAN-only-by-accident services to tailnet or loopback.
  4. Document any service that must stay LAN-exposed and why, so the next sweep doesn't re-litigate.
  5. Consider VLAN segmentation for IoT/guest traffic once the router has the capability (likely after the Ubiquiti migration).

Scope - out

  • Mutual TLS / per-service auth uplift. Tailnet identity is the auth layer for now; service-level auth is a later concern.
  • Anything requiring router VLAN support before the Ubiquiti migration.

Why now

Posture work that's cheap to start and compounds. Doesn't block on hardware.

Filed by Claude.

**Problem** Today the LAN is implicitly treated as a trust boundary - devices on the home network can reach each other and reach kai-server's LAN-side surface without per-flow authentication. That's the conventional home posture but it's wrong for Kai's actual threat model: a router compromise, an IoT device compromise, or a guest-device compromise all become full LAN access. **Goal** Move from 'LAN = trust boundary' to 'LAN = routing boundary, tailnet = trust boundary.' kai-server already does this for SSH (tailnet-only); extend the pattern. **Scope - in** 1. Inventory every service on every coilysiren-owned host that currently listens on the LAN interface. Build the list before changing anything. 2. For each service, decide: (a) tailnet-only, (b) loopback + tailnet, or (c) genuinely needs LAN exposure (printers, Chromecast-style devices). 3. Bind LAN-only-by-accident services to tailnet or loopback. 4. Document any service that must stay LAN-exposed and why, so the next sweep doesn't re-litigate. 5. Consider VLAN segmentation for IoT/guest traffic once the router has the capability (likely after the Ubiquiti migration). **Scope - out** - Mutual TLS / per-service auth uplift. Tailnet identity is the auth layer for now; service-level auth is a later concern. - Anything requiring router VLAN support before the Ubiquiti migration. **Why now** Posture work that's cheap to start and compounds. Doesn't block on hardware. **Filed by Claude.**
coilysiren added
P4
 and removed
P3
 labels 2026-05-31 07:00:40 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dispatch/issue-294
tangled-knot
dispatch/issue-216
No results found.
Labels
Clear labels
  
P0
now / blocking / urgent

  
P1
next / important

  
P2
backlog / will do

  
P3
someday / low

  
P4
icebox / frozen / reopen if it becomes real

No labels
P0
P1
P2
P3
P4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/infrastructure#110
No description provided.