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

tailscale-devices: sweep existing sidecars to re-auth with rich tag set #146

New issue
Open
opened 2026-05-26 20:12:46 +00:00 by coilysiren · 0 comments
coilysiren commented 2026-05-26 20:12:46 +00:00
Owner
Copy link

Problem

After coilysiren/infrastructure#144 + #145 landed, every tailscale_tailnet_key minted by terraform/tailscale-devices/ carries the rich tag set: [tag:k8s, tag:svc-<service>, tag:host-kai-server]. But the existing sidecar devices still carry only tag:k8s, because they're using their persisted ts-state Secret from first boot and won't re-auth on their own.

Consequence: the tailnet admin console answers "which deployment is this device" only for future sidecars (re-deployed or new). Existing devices stay anonymous under tag:k8s until manually bounced.

Change

Per-namespace sweep:

for svc in 2fauth backend backend-db eco-mcp eco-spec forgejo galaxy-gen ntfy repo-recall signoz vmsingle; do
  ns=...   # actual namespace varies; pull from each repo's deploy manifest
  coily ops kubectl --context=kai-server -n "$ns" delete secret "ts-state-$svc"
  coily ops kubectl --context=kai-server -n "$ns" rollout restart deployment/<sidecar-pod>
  coily ops kubectl --context=kai-server -n "$ns" rollout status deployment/<sidecar-pod> --timeout=2m
done

The actual command shape varies per deployment - some sidecars share a Deployment with the app, some are separate. Best to do this as a per-service issue tree or a single sweep script that knows each service's namespace + pod selector.

Expected outcome

After the sweep, coily tailscale status shows each sidecar with its tag:svc-<service> + tag:host-kai-server, and the admin console can answer "which physical host runs this deployment" without operator knowledge.

Out of scope

  • Adding ACL rules keyed on tag:svc-<service> (e.g. "only tag:svc-forgejo reaches the forgejo DB"). Tags are now in place to support that work but no rules are using them yet.
  • Adding tag:svc-<service> to actual ACL src/dst - the rich tags just sit in tagOwners until someone uses them.

Filed by Claude.

**Problem** After coilysiren/infrastructure#144 + #145 landed, every `tailscale_tailnet_key` minted by `terraform/tailscale-devices/` carries the rich tag set: `[tag:k8s, tag:svc-<service>, tag:host-kai-server]`. But the **existing sidecar devices** still carry only `tag:k8s`, because they're using their persisted `ts-state` Secret from first boot and won't re-auth on their own. Consequence: the tailnet admin console answers "which deployment is this device" only for *future* sidecars (re-deployed or new). Existing devices stay anonymous under `tag:k8s` until manually bounced. **Change** Per-namespace sweep: ``` for svc in 2fauth backend backend-db eco-mcp eco-spec forgejo galaxy-gen ntfy repo-recall signoz vmsingle; do ns=... # actual namespace varies; pull from each repo's deploy manifest coily ops kubectl --context=kai-server -n "$ns" delete secret "ts-state-$svc" coily ops kubectl --context=kai-server -n "$ns" rollout restart deployment/<sidecar-pod> coily ops kubectl --context=kai-server -n "$ns" rollout status deployment/<sidecar-pod> --timeout=2m done ``` The actual command shape varies per deployment - some sidecars share a Deployment with the app, some are separate. Best to do this as a per-service issue tree or a single sweep script that knows each service's namespace + pod selector. **Expected outcome** After the sweep, `coily tailscale status` shows each sidecar with its `tag:svc-<service>` + `tag:host-kai-server`, and the admin console can answer "which physical host runs this deployment" without operator knowledge. **Out of scope** - Adding ACL rules keyed on `tag:svc-<service>` (e.g. "only tag:svc-forgejo reaches the forgejo DB"). Tags are now in place to support that work but no rules are using them yet. - Adding `tag:svc-<service>` to actual ACL src/dst - the rich tags just sit in tagOwners until someone uses them. Filed by Claude.
coilysiren added
P4
 and removed
P3
 labels 2026-05-31 07:00:38 +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#146
No description provided.