Archive / Page 2
As your teams grow and become more distributed, it makes sense to limit an employee’s access based on their job function rather than to give everyone persistent access to your production environment. This not only lets you manage sensitive resources such as customer data more effectively, but it also reduces the risk of accidentally impacting production — for example, by running a query meant for your staging environment. This doesn’t mean you want to prevent the legitimate use of these resources, such as when someone’s on call, but simply to ensure they only have access when they’re on call.
Following the principle of least privilege, teams should limit access to sensitive production resources to only those who need it, and only when they need it. Tailscale ACLs already let you manage access to company resources and restrict access by default with “default deny” rules. But what if someone needs access to a server they don’t normally use? That’s why we’re excited to partner with Indent — so members of your team can easily request, and reviewers can easily approve, time-bounded access to these resources without ever leaving Slack.
Tailscale lets you connect your computers to each other so that you can use them together securely. As technology continues to advance, we’ll be carrying around more and more devices that, for convenience, we’ll call “computers.” Some of them are more limited than others, but today I want to talk about one device in particular: the Steam Deck by Valve.
The Steam Deck is a handheld Linux computer that is used for playing desktop-grade PC games. Its portability allows you to take your Steam library on the go with you anywhere, just like a Nintendo Switch. The Deck is also notable because it runs a variant of Arch Linux called SteamOS. Valve’s philosophy is that the Steam Deck is just a PC. It is open and hackable for anyone to modify to fit their needs. Valve even gives you the drivers to install Windows on the Deck, in case you want to.
Today we’re delighted to introduce Tailscale SSH, to more easily manage SSH connections in your tailnet. Tailscale SSH allows you to establish SSH connections between devices in your Tailscale network, as authorized by your access controls, without managing SSH keys, and authenticates your SSH connection using WireGuard®.
Many organizations already use Tailscale to protect their SSH sessions — for example, to allow users to connect from their work laptop to their work desktop. Since Tailscale allows you to connect your devices in a virtual private network, and use access controls to restrict communications between them, we thought, “Why do we need SSH keys? Let’s just make SSH use your Tailscale identity.” And so we did.
For sensitive high-risk connections, such as those connecting as
root, you can also enable check mode. Check mode requires a user to re-authenticate with your SSO (or to have recently re-authenticated) before being able to establish a Tailscale SSH connection.
Read on to learn more about what Tailscale SSH is, how it compares to other SSH solutions, and how to start using it in your tailnet.
Tailscale runs on many platforms, including macOS, and has a macOS version available in the App Store. If you’re using macOS at work, however, your team might not be able to roll out Tailscale to your entire organization if not everyone has an Apple ID. In this case, it’s common to use a mobile device management (MDM) solution that allows you to distribute applications that are not available in the App Store.
Starting with Tailscale v1.26, you can install Tailscale as a standalone macOS application. The standalone macOS application has all the same functionality as the version distributed in the App Store.
At Tailscale, we are ridiculously passionate about security and privacy—so much so that we built a product that, by design, can’t see your data. We don’t even want to see your data. Behind the scenes, we’ve been completing security audits, working with expert cryptographers to validate our key management, and ensuring we lock down access to our production environment.
We’re excited to announce that we’ve received our SOC 2 Type I report, reaffirming our commitment to security. Let’s dig into how Tailscale applies security controls to protect your information.
You can use Tailscale to securely connect to the resources you need for development, including internal tools and databases, no matter where you are or where your development environment lives.
Today, as part of DockerCon, we’re excited to launch our Tailscale Docker Desktop extension. The Tailscale extension for Docker Desktop makes it easy to share exposed container ports from your local machine with other users and devices on your tailnet.
Use Tailscale in Docker Desktop to share a staged copy of your work with a colleague as part of a code review, or share in-progress feedback with teammates. Or access production resources from your development environment, such a database, a package registry, or a licensing server. Because Tailscale works with SSO from your identity provider, Tailscale makes it easier to safely share what you’re working on with anyone in your organization, based on access controls.
This is an interview with Tailscale co-founder and CTO David Crawshaw from CyberNews, reprinted with permission.
The impressive technological progress led to a variety of exciting developments, such as the emergence of the cloud and wireless technology. With our lives being so interconnected with the digital realm, can we still have the same level of privacy as a few decades ago?
In this guest post, Elias Naur walks us through running Tailscale on Android TV.
Running Tailscale on an Android TV device is useful for the situations where you’re trying to connect to a big screen, but can’t use a desktop or mobile device. For example, you might want to access your home media server to watch your favorite TV shows when you’re on the go in a hotel room or Airbnb, and only have an Android TV stick to connect to the provided TV.
Read on for technical details on how we made this possible.
TL;DR: Tailscale’s free plan is free because we keep our scaling costs low relative to typical SaaS companies. We care about privacy, so unlike some other freemium models, you and your data are not the product. Rather, increased word-of-mouth from free plans sells the more valuable corporate plans. I know, it sounds too good to be true. Let’s see some details.
When you connect to a web application on your tailnet over plain HTTP, you might get a security warning in your browser. Although your tailnet’s connections use WireGuard, which provides end-to-end encryption at the network layer, your browser isn’t aware of that encryption—so it looks for a valid TLS certificate for that domain. For internal web apps, this can be confusing to your users, so Tailscale already allows you to provision HTTPS certificates from Let’s Encrypt for your internal web applications, with
If you’re running a public web server, though, it will need to get the certificate from Tailscale to serve your sites over HTTPS on your tailnet. Caddy is an open source web server—and unlike most web servers, it provisions and manages HTTPS certificates for you. (We love it because it uses HTTPS by default!) Caddy also manages renewing these certificates automatically.
With the beta release of Caddy 2.5, Caddy automatically recognizes and uses certificates for your Tailscale network (
*.ts.net), and can use Tailscale’s HTTPS certificate provisioning when spinning up a new service.
Devices you add to your Tailscale network will periodically expire their node keys and force users to reauthenticate, to ensure the devices are still meant to be on your network.
In Tailscale, ACL tags provide a way to assign an identity to a device, which replaces the prior user authentication on that device. So, node key expiry might be surprising behavior for tagged devices, such as servers, which do not have a user associated with them.
Starting today, tagged devices will have key expiry disabled by default.
You can use subnet routers in Tailscale to easily connect an existing network you have to your tailnet—for example, a virtual private cloud, or an on-premises legacy network. To set up a subnet router, you advertise routes from the device, and then approve these from the admin console. But what if you’re spinning up multiple subnet routers in high-availability mode? Or multiple exit nodes?
We’re introducing the concepts of
autoApprovers for routes and exit nodes. This lets you specify in your ACL file which users can self-approve routes and exit nodes. This means that you can set up a subnet router or an exit node with just one CLI command on the device.
ACL tags can be applied to a Tailscale device in order to manage access permissions based on its tag. Tailscale already allows you to manage access to devices based on their names, rather than IP addresses; and tags take this a step further, so you can manage access to devices based on their purpose. For example, you might tag a production server
prod and a production database
prod, and allow all
prod devices to communicate with each other in your network, rather than specifying each device individually.
We’re excited to announce ACL tags are now generally available! What does this mean for you? You can include tags as part of an authentication key, you can tag devices from the admin console, and tags can be owners of other tags. And we’ve further locked down ACL tags, so that authentication is required when re-tagging a device. ACL tags are a free feature, available in all pricing tiers.
We’ve added more user roles to make it easier to manage access to your network. Now, in addition to your tailnet Owner, Admins, and Members, you can give users the roles of Network Admin, IT Admin, and Auditor. This lets users access the admin console without the full permissions of an Admin.
Have you moved to a remote development environment? In reality, you can rarely develop fully in isolation—you need access to internal tools and services to make sure your code works as expected. So although your development environment moved, well, it’s likely nothing else did.
If you already didn’t have a great way to access internal development resources before, then having an ephemeral VM in a cloud provider spinning up and down as you need it for development doesn’t make that any easier. Especially if it’s not just your development environment, but every user in your organization’s.
Luckily, Tailscale works as part of a dev container with a reusable auth key, so that every GitHub Codespace you spin up can automatically connect to your tailnet. You can use Tailscale to access resources on your tailnet, or to share your development environment with others.
When you’re developing software, you need to access all kinds of resources, including package registries, container image registries, databases, and other network services. You want to work with those services securely and with low latency, wherever they are, even if they’re behind a firewall or don’t have a public IP address. Most importantly, though, you need to be able to access your coworkers: when you need a code review, or you’re pair programming, you want to be able to easily share your development environment with others so they can see what you’re working on. From a development workspace in Coder, you can access resources you need for development, and share what you’re working with your coworkers with Tailscale.
Remote development is hard. You need access to all the things from wherever you happen to be working from this week. It could be a coffee shop, the train, or even (gasp!) the office. In an ideal world, it shouldn’t take longer to gain access to what you need to get your work done, including cloud and on-prem resources, than it does to complete the tasks at hand.
Developing remotely should be a boon, not a bottleneck, that’s why we’re excited to partner with Gitpod. We aim to make it easy to connect a running workspace in Gitpod to your resources and your colleagues using Tailscale—with Tailscale available by default in Gitpod workspaces, and Gitpod free for a year to Tailscale customers.
The world doesn’t need more words about remote meetings. So here’s a picture:
Given that this week is the epic all-things-cloud-native reunion in LA, we thought we might crash your little party and mention that Tailscale already works well with containers and Kubernetes. Many of us here at Tailscale used to work on Kubernetes, and keep it close to our hearts even if we’re not at KubeCon this week (and sorry, we love YAML, but use HuJSON now).
Tailscale 1.16 is out! The latest Linux, Windows, and Android clients are available today (see our update instructions), while macOS and iOS will be available over the next few days, pending App Store reviews.
We break down the work that’s happened in and around the release of Tailscale 1.16.