You simply create it in the admin console, on the Keys page, like any other key: Generating an ephemeral authentication key will be simple, once the feature is available to use. This means that if such machines go offline for a short period of time, they are assumed to be gone forever, and Tailscale will automatically remove them from your network. But when signed up with an ephemeral key, Tailscale will assume that these machines themselves are “ephemeral”, or temporary. So we generate a new machine key, and sign these containers into Tailscale as normal. The idea is that since multiple container instances can be running concurrently, it makes sense to treat them all as different machines. So we devised another solution: ephemeral authentication keys. While that may be acceptable in a lot of cases, it’s not ideal. So while the GitHub Action would work great as long as there was only one instance of it running, as soon as another Action starts concurrently, the two containers would start battling each other as the One True Machine represented by the key. The thing about this machine-specific key is that it’s supposed to be unique - only one machine is supposed to have it at any given time. That’s great, that’s exactly what we want. So every time it starts up, the container uses the same identity as last time. He generated the machine-specific key once, stored it as a GitHub Actions secret, and then piped it into the container before starting Tailscale. This issue can be somewhat resolved with a very clever hack, like the one Tavian Barnes used with his FreeBSD CI GitHub Action. Not pictured: 36 more of these that I deleted by hand. So you end up with a new machine registered on your network every time a container spins up. The container itself forgets its identity with every fresh boot, but your Tailscale network doesn’t. This sounds like it could be fine, until you realize that Docker containers are supposed to be stateless. Secondly, the moment you sign onto your Tailscale network, your device is registered there permanently, at least until you go to the admin console and remove it. This is a solved problem, though - with authentication keys, you can tailscale up without any user interaction. It would be very inconvenient to have to manually approve your CI every time it runs. That works for me, but there are a couple of reasons why you can’t just tailscale up.įirstly, when you do tailscale up, you’re given a URL on your terminal that you need to open and sign into Tailscale on in order to authorize this node to join your network. But that means that for the GitHub Action to be able to access my server, it too must join my Tailscale network. It sounds like a great idea security-wise expose SSH only over Tailscale, so the only devices that can access your server at all are the devices on your trusted network. The only problem is that my server’s SSH is accessible only over Tailscale. Armed with this confidence, I devised a plan - a GitHub Action that builds the binary, packages it along with the pages and static files, then pushes the package and restarts the server automatically. The biggest annoyance in this server is deployment every change I make needs to be pulled on the server-side, potentially recompiled if the Go code changes, and restarted.Īutomating all this should be DevOps 101 - which is convenient for me since being a university student is about the time I figure I should be doing DevOps 101. Recently, I’ve started blogging, and to serve the raw Markdown into delicious HTML and CSS, I wrote a basic web server in Go that compiles Markdown and then injects it into a template and serves it over HTTP.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |