4 ms·
I think y’all are talking about different things; the parent comment seems to be talking about injecting additional keys into the tailnet (basically, letting ot
by akerl_ 4y ago
I think y’all are talking about different things; the parent comment seems to be talking about injecting additional keys into the tailnet (basically, letting other devices communicate inside your Wireguard VPN).
- dvzk 4y agoThat's actually the point of this feature. Before, the key distribution server could add unauthenticated Wireguard nodes to your peer list. Now, the tailnet administrator can tell Tailscale nodes to reject new peer public keys unless the key is cryptographically signed by a trusted node. If you don't trust the implementation, wait until it's audited, I guess.
- nine_k 4y agoI wonder if a third-party solution for the signature key distribution is feasible; I suppose it should be, because it's appears to be just a file. This way, if you don't trust Tailscale to distribute these lock-controlling keys, you could run a different mechanism of your choosing that would effectively control what nodes are automatically admitted.
- dvzk 4y agoBased on the article, the private keys for peer enrollment signing are generated locally on each Tailscale client and aren't distributed at all. I don't see why you couldn't write a custom client that approves or denies new peers based on your own criteria. Some of the internal Tailscale API may first need to be officially documented.