I've been running Tailscale in a moderately complex lab and production-adjacent environment for about eighteen months now, primarily to facilitate secure communication between microservices across hybrid cloud and to provide a managed alternative to our old OpenVPN setup for developer access. Overall, I'm a strong advocate—the concept of a zero-config WireGuard overlay managed by a control plane is elegant, and for the most part, it just works. However, there's one persistent friction point that has begun to grate on me, particularly as our node count has grown: the device approval flow.
My core issue is that the requirement for explicit approval for every new node, even within a "trusted" user's domain, feels increasingly at odds with the seamless, zero-trust-underpinnings the product otherwise promotes. I understand the security rationale, especially for the initial login from a new device. But consider my typical workflow, which I suspect is not unique:
* A developer spins up a new ephemeral container or a temporary cloud instance for testing a component of our event-driven pipeline. This node needs to join the tailnet to communicate with Kafka brokers and other services.
* I, as the tailnet admin, receive a notification. I must then context-switch to the admin console to approve the device.
* The approval is for the *machine*, not just the user. If that container is torn down and recreated (a common occurrence), even with the same node name and same user, it requires *another* approval.
This creates a bottleneck and a point of failure. For automated, infrastructure-as-code deployments, this is a significant hurdle. While I'm aware of the "no-login" authentication methods like auth keys, they come with their own trade-offs in terms of key management and granularity that aren't always ideal for dynamic, short-lived workloads where you might still want some audit trail tied to a user identity.
My configuration for a typical ephemeral node using a service account might look like this:
```yaml
# docker-compose snippet for a service
version: '3.8'
services:
stream-processor:
image: my-app:latest
command: >
/bin/sh -c "
tailscale up --authkey=${TS_AUTH_KEY} --hostname=ephemeral-processor-$(HOSTNAME) --advertise-tags=tag:ephemeral,tag:prod &&
./start-app.sh
"
environment:
TS_AUTH_KEY: ${TS_AUTH_KEY}
cap_add:
- NET_ADMIN
- NET_RAW
volumes:
- /dev/net/tun:/dev/net/tun
```
Even with an auth key, if that key is set to require approval for new devices (a sensible default for many orgs), the problem persists. The alternative is to use a pre-approved auth key, which then feels like a bypass of the security model I'm trying to uphold.
My questions to the community are:
* Are others running into this, particularly in automated or containerized environments?
* What workarounds or patterns have you established? Are you using ACL tags heavily to gate access *after* the device is approved, thus making the approval step itself less sensitive?
* Has anyone successfully scripted the approval API to auto-approve devices with specific tags or from specific users, and if so, what are the hidden pitfalls of that approach?
I'm left wondering if I'm misconfiguring something, or if this is simply the intended trade-off—a bit of administrative friction in exchange for a clear, auditable device join event. Perhaps my expectation for fully automated, user-authenticated but admin-unattended node joining is asking for a contradiction in terms within the zero-trust model.
testing all the things
throughput first