Skip to content
Notifications
Clear all

Has anyone tried the Tailscale SSH certificate authority at scale?

2 Posts
2 Users
0 Reactions
3 Views
(@integration_jane_new)
Estimable Member
Joined: 4 months ago
Posts: 111
Topic starter   [#12942]

Having recently completed an audit of our internal SSH key management infrastructure, I have been conducting a thorough evaluation of Tailscale's SSH certificate authority (CA) as a potential replacement for our existing, somewhat brittle, key-based authentication system. The documented promise of short-lived certificates automatically issued to Tailscale-authenticated nodes is architecturally compelling, particularly for ephemeral workloads. However, the available case studies and documentation primarily focus on small-team or ad-hoc access scenarios.

My primary inquiry pertains to operational experiences at scale, which I define here as an environment comprising several hundred to low-thousands of managed nodes, with a need for granular role-based access controls (RBAC), comprehensive audit logging, and seamless integration into existing DevOps and security toolchains.

I am interested in concrete details regarding the following dimensions:

* **Performance of the CA under load:** What is the observed latency for certificate issuance during concurrent node provisioning events, such as an autoscaling event spawning 50-100 new instances simultaneously? Does the Tailscale coordination server or the on-premises coordination server (headscale) become a bottleneck?
* **RBAC and Policy Management Complexity:** The `tailscale` ACL tags and SSH rules appear serviceable for defining *which* nodes a user can access. However, for controlling *what commands* can be executed (e.g., restricting a deployment service account to run only `sudo systemctl restart appX`), one must rely on the target's `authorized_keys` command= restrictions, as the Tailscale CA does not embed these restrictions in the certificate itself. Has anyone built a layered policy enforcement model, perhaps combining Tailscale SSH access with a downstream tool like `sudo` or a centralized policy agent?
* **Certificate Lifecycle and Renewal Reliability:** In practice, how robust is the background renewal process for long-running services? Are there observed edge cases where a renewal failure leads to an access outage, and what monitoring strategies have proven effective?
* **Integration with Existing Configuration Management:** For nodes provisioned by tools like Ansible, Terraform, or Puppet, what is the recommended pattern for bootstrapping Tailscale and the SSH CA? Is it a matter of injecting a node key via user-data, or have you implemented a more nuanced approach?

A snippet of a typical ACL configuration we are testing for structured access illustrates the current pattern:

```json
// tailscale policy file excerpt
"ssh": [
{
"action": "accept",
"src": ["tag:database-admins"],
"dst": ["tag:postgres-cluster"],
"users": ["ubuntu", "postgres"]
},
{
"action": "accept",
"src": ["tag:ci-cd"],
"dst": ["tag:application-servers"],
"users": ["deployer"]
}
]
```

The abstraction is clean, but the practical management of these tags and their mapping to dynamic inventories remains an open question. I am particularly keen to hear about pitfalls in logging and audit trail generation—does the Tailscale audit log sufficiently capture the `principal` (user) to `certificate` mapping for all SSH sessions in a way that is easily consumable by a SIEM?

Any detailed reports on stability, administrative overhead, or unexpected integration costs in a scaled deployment would be immensely valuable to my analysis.



   
Quote
(@infra_auditor_nina)
Reputable Member
Joined: 4 months ago
Posts: 159
 

> several hundred to low-thousands of managed nodes
That's the zone where the seams start showing. The CA's performance is fine until you get a few dozen nodes trying to join during a major deployment or a regional failover. I've seen issuance latency spike from milliseconds to several seconds, which can cause provisioning timeouts in rigid automation.

The bigger issue is the audit logging. Their logs are decent for "who accessed what", but they're a black box for internal CA operations. When you need to prove to an auditor that a specific certificate was issued with the correct principals at a precise time, you're stuck exporting and parsing JSON. There's no integrated, immutable trail.

Have you considered how you'd handle a forced rotation of your tailnet's CA key? That's the scale question nobody wants to answer.


- Nina


   
ReplyQuote