Hey folks, been running Tailscale across my homelab and a few cloud VMs for a while now. I'm deep into automating everything with AI agents and infra-as-code, which leads me to my current puzzle.
I'm trying to formalize my setup and I keep circling back to: when should I use a service account versus a regular human user account in Tailscale? The docs mention both, but I'm looking for the *operational* differences and best practices from those running this in production-like environments.
Some specific scenarios I'm juggling:
* A CI/CD runner (like GitHub Actions) that needs to deploy to a private Tailscale subnet.
* A monitoring agent (e.g., Prometheus node_exporter) that needs to be accessed from my monitoring server.
* An automated backup script that pulls files from several machines.
* Compared to my own developer account, which I use for SSH.
What I'm curious about:
- **Authentication Flow:** Service accounts seem to use auth keys. Is the main benefit just that they're non-expiring (unless revoked) and lack MFA? Do you store these keys like any other secret?
- **ACL & Tagging:** I see you can tag devices for service accounts. Does tagging service accounts work better for ACL management than assigning a human user to a machine?
- **Ephemeral vs. Persistent:** For short-lived workloads (like a CI job), are ephemeral auth keys with a service account the way to go?
- **Audit Trail:** When something goes wrong, is it easier to trace "service-account-backup" vs. "johns-laptop"?
Here's a snippet of how I'm currently provisioning a machine with a service account key, but I'm not sure if this is optimal:
```json
# tailscale up command using an auth key (sensitive, stored in vault)
tailscale up --authkey=tskey-auth-somestringhere --hostname=prod-db-backup
```
Would love to hear how you all are structuring this, especially if you've hit any pitfalls with one approach over the other. Any gotchas with ACLs when mixing service and human users?
--experiment
Prompt engineering is the new debugging.
I run Tailscale for 20+ nodes across our fintech startup's hybrid cloud. We use service accounts for our CI/CD, monitoring, and database syncs.
**Auth keys and lifespan**: Service accounts rely on pre-auth keys. The operational difference is you're managing a secret instead of a user session. We store them in Vault, not as env vars. Human accounts expire if you use SSO; service keys don't. That's the point.
**Permission scaling with tags**: This is the main win. Tagging service accounts (or their enrolled devices) is cleaner than user-based ACLs for automation. You can tag `ci:prod` and scope ACLs to that tag only. For a human user, you're usually granting broader network-level access for SSH or web UIs.
**Audit and ownership**: A human user account ties an action to a person in the admin console. A service account action is just "ci-bot-1". You lose that link. We prefix all our service account device names (`svc-backup-primary`) so they don't get confused with dev machines.
**Cost**: If you're on a per-user tier, service accounts count as seats. That's often the hidden cost everyone misses. At our scale, it's about $4/user/mo, so we budget for them.
For your CI/CD and monitoring agent, use a service account with tags. For your backup script, also a service account, but maybe a different one with its own ACLs. Your developer account stays human. The rule is simple: if it's non-interactive automation, it's a service account. The real question is how many distinct permission sets you need. Tell us if you're on the free plan or a paid tier, and how many separate automated jobs you're actually running.
Your favorite tool is probably overpriced.
Your point about audit loss is critical. In our setup, we mitigate that by requiring every service account's pre-auth key issuance to be logged in a separate system with a justification ticket and an owner's email. The action in Tailscale is still just "svc-prometheus," but we have an external audit trail linking it back to a human who requested it and for what purpose.
I'd also stress the operational overhead you've hinted at. Managing a service account isn't just creating a key; it's the full lifecycle. When that automated backup script is deprecated, you must remember to revoke the key and decommission the device. We've found that pairing service accounts with ephemeral tags, like `project:backup-2024`, helps. When the project ends, the ACL rule for that tag is removed, effectively disabling the account even if the key isn't immediately revoked.
show me the SLA