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

Verify kai-server k3s API is locked to the tailnet - deny vs dial #167

New issue
Open
opened 2026-05-28 09:35:28 +00:00 by coilysiren · 0 comments
coilysiren commented 2026-05-28 09:35:28 +00:00
Owner
Copy link

Question

Is the kai-server k3s Kubernetes API (:6443) actually locked to the tailnet - i.e. does it deny connections originating outside Tailscale - or is it merely dialed over the tailnet by clients while still accepting connections from the LAN/WAN?

Why the kubeconfig can't answer this

A kubeconfig is client-side only. It carries the server: URL, the CA bundle (to verify the server), and client creds. None of that enforces a network restriction. A tailnet server: URL (e.g. https://100.69.164.66:6443) constrains the client's route, not the cluster's accept policy. The CA cert in the kubeconfig also does not reveal the serving cert's SANs. So the lock question has to be answered from server-side config on kai-server.

What to check on kai-server

  • apiserver bind / advertise address - k3s --bind-address, --advertise-address, --node-ip. Stock k3s binds 0.0.0.0:6443, which is not tailnet-locked on its own.
  • host firewall - ufw / nftables / iptables. Is :6443 restricted to the tailscale interface (tailscale0) or the 100.64.0.0/10 CGNAT range, or is it open on the LAN/WAN?
  • Tailscale ACLs - do the tailnet ACLs gate :6443?
  • reachability - is :6443 reachable from a LAN host or via the public IP / any NAT port-forward? (the actual test of "locked or not")
  • TLS SANs - k3s --tls-san list (informational - tells you which addresses the serving cert presents, not what is accepted).

Acceptance

  • Documented answer: locked to the tailnet, or not.
  • If not locked: follow-up to restrict the apiserver to the tailscale interface (bind address and/or firewall rule), then re-verify from a non-tailnet path.

Context

Came up while wiring a local kai-server kubeconfig context on the Windows tower. Tailnet address resolved from SSM /coilysiren/kai-server/tailnet-ip.

## Question Is the kai-server k3s Kubernetes API (`:6443`) actually locked to the tailnet - i.e. does it **deny** connections originating outside Tailscale - or is it merely **dialed** over the tailnet by clients while still accepting connections from the LAN/WAN? ## Why the kubeconfig can't answer this A kubeconfig is client-side only. It carries the `server:` URL, the CA bundle (to verify the server), and client creds. None of that enforces a network restriction. A tailnet `server:` URL (e.g. `https://100.69.164.66:6443`) constrains the client's route, not the cluster's accept policy. The CA cert in the kubeconfig also does not reveal the serving cert's SANs. So the lock question has to be answered from server-side config on kai-server. ## What to check on kai-server - **apiserver bind / advertise address** - k3s `--bind-address`, `--advertise-address`, `--node-ip`. Stock k3s binds `0.0.0.0:6443`, which is not tailnet-locked on its own. - **host firewall** - ufw / nftables / iptables. Is `:6443` restricted to the tailscale interface (`tailscale0`) or the `100.64.0.0/10` CGNAT range, or is it open on the LAN/WAN? - **Tailscale ACLs** - do the tailnet ACLs gate `:6443`? - **reachability** - is `:6443` reachable from a LAN host or via the public IP / any NAT port-forward? (the actual test of "locked or not") - **TLS SANs** - k3s `--tls-san` list (informational - tells you which addresses the serving cert presents, not what is accepted). ## Acceptance - Documented answer: locked to the tailnet, or not. - If **not** locked: follow-up to restrict the apiserver to the tailscale interface (bind address and/or firewall rule), then re-verify from a non-tailnet path. ## Context Came up while wiring a local `kai-server` kubeconfig context on the Windows tower. Tailnet address resolved from SSM `/coilysiren/kai-server/tailnet-ip`.
coilysiren added
P2
 and removed
P1
 labels 2026-05-31 07:00:34 +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#167
No description provided.