About Maya

• Tailscale: https://tailscale.com/
• Tailscale features:
  • VS Code extension: https://marketplace.visualstudio.com/items?itemName=tailscale.vscode-tailscale 
  • Tailscale SSH: https://tailscale.com/kb/1193/tailscale-ssh 
  • Tailnet lock: https://tailscale.com/kb/1226/tailnet-lock 
  • Auto updates: https://tailscale.com/kb/1067/update#auto-updates 
  • ACL tests: https://tailscale.com/kb/1018/acls#tests 
  • Kubernetes operator: https://tailscale.com/kb/1236/kubernetes-operator 
  • Log streaming: https://tailscale.com/kb/1255/log-streaming 
• Tailscale Security Bulletins: https://tailscale.com/security-bulletins 
• Blog post “How Our Free Plan Stays Free:” https://tailscale.com/blog/free-plan 
• Tailscale on AWS Marketplace: https://aws.amazon.com/marketplace/pp/prodview-nd5zazsgvu6e6 
  
  

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn, and I am joined today on this promoted guest episode by my friends over at Tailscale. They have long been one of my favorite products just because it has dramatically changed the way that I interact with computers, which really should be enough to terrify anyone. My guest today is Maya Kaczorowski, Chief Product Officer at Tailscale. Maya, thanks for joining me.

Maya: Thank you so much for having me.

Corey: I have to say originally, I was a little surprised to—“Really? You’re the CPO? I really thought I would have remembered that from the last time we hung out in person.” So, congratulations on the promotion.

Maya: Thank you so much. Yeah, it’s exciting.

Corey: Being a product person is probably a great place to start with this because we’ve had a number of conversations, here and otherwise, around what Tailscale is and why it’s awesome. I don’t necessarily know that beating the drum of why it’s so awesome is going to be covering new ground, but I’m sure we’re going to come up for that during the conversation. Instead, I’d like to start by talking to you about just what a product person does in the context of building something that is incredibly central not just to critical path, but also has massive security ramifications as well, when positioning something that you’re building for the enterprise. It’s a very hard confluence of problems, and there are days I am astonished that enterprises can get things done based purely upon so much of the mitigation of what has to happen. Tell me about that. How do you even function given the tremendous vulnerability of the attack surface you’re protecting?

Maya: Yeah, I don’t know if you—I feel like you’re talking about the product, but also the sales cycle of talking [laugh] and working with enterprise customers.

Corey: The product, the sales cycle, the marketing aspects of it, and—

Maya: All of it.

Corey: —it all ties together. It’s different facets of frankly, the same problem.

Maya: Yeah. I think that ultimately, this is about really understanding who the customer that is buying the product is. And I really mean that, like, buying the product, right? Because, like, look at something like Tailscale. We’re typically used by engineers, or infrastructure teams in an organization, but the buyer might be the VP of Engineering, but it might be the CISO, or the CTO, or whatever, and they’re going to have a set of requirements that’s going to be very different from what the end-user has as a set of requirements, so even if you have something like bottom-up adoption, in our case, like, understanding and making sure we’re checking all the boxes that somebody needs to actually bring us to work.

Enterprises are incredibly demanding, and to your point, have long checklists of what they need as part of an RFP or that kind of thing. I find that some of the strictest requirements tend to be in security. So like, how—to your point—if we’re such a critical part of your network, how are you sure that we’re always available, or how are you sure that if we’re compromised, you’re not compromised, and providing a lot of, like, assurances and controls around making sure that that’s not the case.

Corey: I think that there’s a challenge in that what enterprise means to different people can be wildly divergent. I originally came from the school of obnoxious engineering where oh, as an engineer, whenever I say something is enterprise grade, that’s not a compliment. That means it’s going to be slow and moribund. But that is a natural consequence of a company’s growth after achieving success, where okay, now we have actual obligations to customers and risk mitigation that needs to be addressed. And how do you wind up doing that without completely hobbling yourself when it comes to accelerating feature velocity? It’s a very delicate balancing act.

Maya: Yeah, for sure. And I think you need to balance, to your point, kind of creating demand for the product—like, it’s actually solving the problem that the customer has—versus checking boxes. Like, I think about them as features, or you know, feature requests versus feature blockers or deal blockers or adoption blockers. So, somebody wants to, say, connect to an AWS VPC, but then the person who has to make sure that that’s actually rolled out properly also wants audit logs and SSH session recording and RBAC-based controls and lots of other things before they’re comfortable deploying that in their environment. And I’m not even talking about the list of, you know, legal, kind of, TOS requirements that they would have for that kind of situation.

I think there’s a couple of things that you need to do to even signal that you’re in that space. One of the things that I was—I was talking to a friend of mine the other day how it feels like five years ago, like, nobody had SOC 2 reports, or very few startups had SOC 2 reports. And it’s probably because of the advent of some of these other companies in this space, but like, now you can kind of throw a dart, and you’ll hit five startups that have SOC 2 reports, and the amount that you need to show that you’re ready to sell to these companies has changed.

Corey: I think that there’s a definite broadening of the use case. And I’ve been trying to avoid it, but let’s go diving right into it. I used to view Tailscale as, oh it’s a VPN. The end. Then it became something more where it effectively became the mesh overlay where all of the various things that I have that speak Tailscale—which is frankly, a disturbing number of things that I’d previously considered to be appliances—all talk to one another over a dedicated network, and as a result, can do really neat things where I don’t have to spend hours on end configuring weird firewall rules.

It’s more secure, it’s a lot simpler, and it seems like every time I get that understanding down, you folks do something that causes me to yet again reevaluate where you stand. Most recently, I was doing something horrifying in front-end work, and in VS Code the Tailscale extension popped up. “Oh, it looks like you’re running a local development server. Would you like to use Tailscale Funnel to make it available to the internet?” And my response to that is, “Good lord, no, I’m ashamed of it, but thanks for asking.” Every time I think I get it, I have to reevaluate where it stands in the ecosystem. What is Tailscale now? I feel like I should get the official description of what you are.

Maya: Well, I sure hope I’m not the official description. I think the closest is a little bit of what you’re saying: a mesh overlay network for your infrastructure, or a programmable network that lets you mesh together your users and services and services and services, no matter where they are, including across different infrastructure providers and, to your point, on a long list of devices you might have running. People are running Tailscale on self-driving cars, on robots, on satellites, on elevators, but they’re also running Tailscale on Linux running in AWS or a MacBook they have sitting under their desk or whatever it happens to be. The phrase that I like to use for that is, like, infrastructure agnostic. We’re just a building block.

Your infrastructure can be whatever infrastructure you want. You can have the cheapest GPUs from this cloud, or you can use the Android phone to train the model that you have sitting on your desk. We just help you connect all that stuff together so you can build your own cloud whatever way you want. To your point, that’s not really a VPN [laugh]. The word VPN doesn’t quite do it justice. For the remote access to prod use case, so like a user, specifically, like, a developer infra team to a production network, that probably looks the most like a zero-trust solution, but we kind of blur a lot of the lines there for what we can do.

Corey: Yeah, just looking at it, at the moment, I have a bunch of Raspberries Pi, perhaps, hanging out on my tailnet. I have currently 14 machines on there, I have my NAS downstairs, I have a couple of EC2 instances, a Google Cloud instance, somewhere, I finally shut down my old Oracle Cloud instance, my pfSense box speaks it natively. I have a Thinkst Canary hanging out on there to detect if anything starts going ridiculously weird, my phone, my iPad, and a few other things here and there. And they all just talk seamlessly over the same network. I can identify them via either IP address, if I’m old, or via DNS if I want to introduce problems that will surprise me at one point or another down the road.

I mean, I even have an exit node I share with my brother’s Tailscale account for reasons that most people would not expect, namely that he is an American who lives abroad. So, many weird services like banks or whatnot, “Oh, you can’t log in to check your bank unless you’re coming from US IP space.” He clicks a button, boom, now he doesn’t get yelled at to check his own accounts. Which is probably not the primary use case you’d slap on your website, but it’s one of those solving everyday things in somewhat weird ways.

Maya: Oh, yeah. I worked at a bank maybe ten years ago, and they would block—this little bank on the east coast of the US—they would block connections from Hawaii because why would any of your customers ever be in Hawaii? And it was like, people travel and maybe you’re—

Corey: How can you be in Hawaii? You don’t have a passport.

Maya: [laugh]. People travel. They still need to do banking. Like, it doesn’t change, yeah. The internet, we’ve built a lot of weird controls that are IP-based, that don’t really make any sense, that aren’t reflective. And like, that’s true for individuals—like you’re describing, people who travel and need to bank or whatever they need to do when they travel—and for corporations, right? Like the old concept—this is all back to the zero trust stuff—but like, the old concept that you were trusted just because you had an IP address that was in the corp IP range is just not true anymore, right? Somebody can walk into your office and connect to the Wi-Fi and a legitimate employee can be doing their job from home or from Starbucks, right? Those are acceptable ways to work nowadays.

Corey: One other thing that I wanted to talk about is, I know that in previous discussions with you folks—sometimes on the podcast sometimes when I more or less corner someone a Tailscale at your developer conference—one of the things that you folks talk about is Tailscale SSH, which is effectively a drop-in replacement for the SSH binary on systems. Full disclosure, I don’t use it, mostly because I’m grumpy and I’m old. I also like having some form of separation of duties where you’re the network that ties it all together, but something else winds up acting as that authentication step. That said, if I were that interesting that someone wanted to come after me, there are easier ways to get in, so I’m mostly just doing this because I’m persnickety. Are you seeing significant adoption of Tailscale SSH?

Maya: I think there’s a couple of features that are missing in Tailscale SSH for it to be as adopted by people like you. The main one that I would say is—so right now if you use Tailscale SSH, it runs a binary on the host, you can use your Tailscale credentials, and your Tailscale private key, effectively, to SSH something else. So, you don’t have to manage a separate set of SSH keys or certs or whatever it is you want to do to manage that in your network. Your identity provider identity is tied to Tailscale, and then when you connect to that device, we still need to have an identity on the host itself, like in Unix. Right now, that’s not tied to Tailscale. You can adopt an identity of something else that’s already on the host, but it’s not, like, corey@machine.

And I think that’s the number one request that we’re getting for Tailscale SSH, to be able to actually generate or tie to the individual users on the host for an identity that comes from, like, Google, or GitHub, or Okta, or something like that. I’m not hearing a lot of feedback on the security concerns that you’re expressing. I think part of that is that we’ve done a lot of work around security in general so that you feel like if Tailscale were to be compromised, your network wouldn’t need to be compromised. So, Tailscale itself is end-to-end encrypted using WireGuard. We only see your public keys; the private keys remain on the device.

So, in some sense the, like, quote-unquote, “Worst” that we could do would be to add a node to your network and then start to generate traffic from that or, like, mess with the configuration of your network. These are questions that have come up. In terms of adding nodes to your network, we have a feature called tailnet lock that effectively lets you sign and verify that all the nodes on your network are supposed to be there. One of the other concerns that I’ve heard come up is, like, what if the binary was compromised. We develop in open-source so you can see that that’s the case, but like, you know, there’s certainly more stuff we could be doing there to prevent, for example, like a software supply chain security attack. Yeah.

Corey: Yeah, but you also have taken significant architectural steps to ensure that you are not placed in a position of undue trust around a lot of these things. Most recently, you raised a Series B, that was $100 million, and the fact that you have not gone bankrupt in the year since that happened tells me that you are very clearly not routing all customer traffic through you folks, at least on one of the major cloud providers. And in fact, a little bit of playing a-slap-and-tickle with Wireshark affirm this, that the nodes talk to each other; they do not route their traffic through you folks, by design. So one, great for the budget, I have respect for that data transfer pattern, but also it means that you are in the position of being a global observer in a way that can be, in many cases, exploited.

Maya: I think that’s absolutely correct. So, it was 18 months ago or so that we raised our Series B. When you use Tailscale, your traffic connects peer-to-peer directly between nodes on your network. And that has a couple of nice properties, some of what you just described, which is that we don’t see your traffic. I mean, one, because it’s end-to-end encrypted, but even if we could capture it, and then—we’re not in the way of capturing it, let alone decrypting it.

Another nice property it has is just, like, latency, right? If your user is in the UK, and they’re trying to access something in Scotland, it’s not, you know, hair-pinning, bouncing all the way to the West Coast or something like that. It doesn’t have to go through one of our servers to get there. Another nice property that comes with that is availability. So, if our network goes down, if our control plane goes down, you’re temporarily not able to add nodes or change your configuration, but everything in your network can still connect to each other, so you’re not dependent on us being online in order for your network to work.

And this is actually coming up more and more in customer conversations where that’s a differentiator for us versus a competitor. Different competitors, also. There’s a customer case study on our website about somebody who was POC’ing us with a different option, and literally during the POC, the competitor had an outage, unfortunately for them, and we didn’t, and they sort of looked at our model, our deployment model and went, “Huh, this really matters to us.” And not having an outage on our network with this solution seems like a better option.

Corey: Yeah, when the network is down, the computers all turn into basically space heaters.

Maya: [laugh]. Yeah, as long as they’re not down because, I guess, unplugged or something. But yeah, [laugh] I completely agree. Yeah. But I think there’s a couple of these kinds of, like, enterprise things that people are—we’re starting to do a better job of explaining and meeting customers where they are, but it’s also people are realizing actually does matter when you’re deploying something at this scale that’s such a key part of your network.

So, we talked a bit about availability, we talked a bit about things like latency. On the security side, there’s a lot that we’ve done around, like I said, tailnet lock or that type of thing, but it’s like some of the basic security features. Like, when I joined Tailscale, probably the first thing I shipped in some sense as a PM was a change log. Here’s the change log of everything that we’re shipping as part of these releases so that you can have confidence that we’re telling you what’s going on in your network, when new features are coming out, and you can trust us to be part of your network, to be part of your infrastructure.

Corey: I do want to further call out that you have a—how should I frame this—a typically active security notification page.

Maya: [laugh].

Corey: And I think it is easy to misconstrue that as look at how terrifyingly insecure this is? Having read through it, I would argue that it is not that you are surprisingly insecure, but rather that you are extraordinarily transparent about things that are relatively minor issues. And yes, they should get fixed, but, “Oh, that could be a problem if six other things happen to fall into place just the right way.” These are not security issues of the type, “Yeah, so it turns out that what we thought was encrypting actually wasn’t and we’re just expensive telnet.” No, there’s none of that going on.

It’s all been relatively esoteric stuff, but you also address it very quickly. And that is odd, as someone who has watched too many enterprise-facing companies respond to third-party vulnerability reports with rather than fixing the problem, more or less trying to get them not to talk about it, or if they do, to talk about it only using approved language. I don’t see any signs of that with what you’ve done there. Was that a challenging internal struggle for you to pull off?

Maya: I think internally, it was recognizing that security was such an important part of our value proposition that we had to be transparent. But once we kind of got past that initial hump, we’ve been extremely transparent, as you say. We think we can build trust through transparency, and that’s the most important thing in how we respond to security incidents. But code is going to have bugs. It’s going to have security bugs. There’s nothing you can do to prevent that from happening.

What matters is how you—and like, you should. Like, you should try to catch them early in the development process and, you know, shift left and all that kind of stuff, but some things are always going to happen [laugh] and what matters in that case is how you respond to them. And having another, you know, an app update that just says “Bug fixes” doesn’t help you figure out whether or not you should actually update, it doesn’t actually help you trust us. And so, being as public and as transparent as possible about what’s actually happening, and when we respond to security issues and how we respond to security issues is really, really important to us. We have a policy that talks about when we will publish a bulletin.

You can subscribe to our bulletins. We’ll proactively email anyone who has a security contact on file, or alternatively, another contact that we have if you haven’t provided us a security contact when you’re subject to an issue. I think by far and large, like, Tailscale has more security bulletins just because we’re transparent about them. It’s like, we probably have as many bugs as anybody else does. We’re just lucky that people report them to us because they see us react to them so quickly, and then we’re able to fix them, right? It’s a net positive for everyone involved.

Corey: It’s one of those hard problems to solve for across the board, just because I’ve seen companies in the past get more or less brutalized by the tech press when they have been overly transparent. I remember that there was a Reuters article years ago about Slack, for example, because they would pull up their status history and say, “Oh, look at all of these issues here. You folks can’t keep your website up.” But no, a lot of it was like, “Oh, file uploads for a small subset of our users is causing a problem,” and so on and so forth. These relatively minor issues that, in aggregate, are very hard to represent when you’re using traffic light signaling.

So, then you see people effectively going full-on AWS status page where there’s a significant outage lasting over a day, last month, and what you see on this is if you go really looking for it is this yellow thing buried in his absolute sea of green lights, even though that was one of the more disruptive things to have happened this year. So, it’s a consistent and constant balance, and I really have a lot of empathy no matter where you wind up landing on that?

Maya: Yeah, I think that’s—you’re saying it’s sort of about transparency or being able to find the right information. I completely agree. And it’s also about building trust, right? If we set expectations as to how we will respond to these things then we consistently respond to them, people believe that we’re going to keep doing that. And that is almost more important than, like, committing to doing that, if that makes any sense.

I remember having a conversation many years ago with an eng manager I worked with, and we were debating what the SLO for a particular service should be. And he sort of made an interesting point. He’s like, “It doesn’t really matter what the SLO is. It matters what you actually do because then people are going to start expecting [laugh] what you actually do.” So, being able to point at this and say, “Yes, here’s what we say and here’s what we actually do in practice,” I think builds so much more trust in how we respond to these kinds of things and how seriously we take security.

I think one of the other things that came out of the security work is we realized—and I think you talked to Avery, the CEO of Tailscale on a prior podcast about some of this stuff—but we realized that platforms are broken, and we don’t have a great way of pushing automatic updates on a lot of platforms, right? You know, if you’re using the macOS store, or the Android Play Store, or iOS or whatever, you can automatically update your client when there is a security issue. On other platforms, you’re kind of stuck. And so, as a result of us wanting to make sure that the fleet is as updated as possible, we’ve actually built an auto-update feature that’s available on all of our major clients now, so people can opt in to getting those updates as quickly as needed when there is a security issue. We want to expose people to as little risk as possible.

Corey: I am not a Tailscale customer. And that bugs me because until I cross that chasm into transferring $1 every month from my bank account to yours, I’m just a whiny freeloader in many respects, which is not at all how you folks who never made me feel I want to be very clear on that. But I believe in paying for the services that empower me to do my job more effectively, and Tailscale absolutely qualifies.

Maya: Yeah, understood, I think that you still provide value to us in ways that aren’t your data, but then in ways that help our business. One of them is that people like you tend to bring Tailscale to work. They tend to have a good experience at home connecting to their Synology, helping their brother connect to his bank account, whatever it happens to be, and they go, “Oh.” Something kind of clicks, and then they see a problem at work that looks very similar, and then they bring it to work. That is our primary path of adoption.

We are a bottom-up adoption, you know, product-led growth product [laugh]. So, we have a blog post called “How Our Free Plan Stays Free” that covers some of that. I think the second thing that I don’t want to undersell that a user like you also does is, you have a problem, you hit an issue, and you write into support, and you find something that nobody else has found yet [laugh].

Corey: I am very good at doing that entirely by accident.

Maya: [laugh]. But that helps us because that means that we see a problem that needs to get fixed, and we can catch it way sooner than before it’s deployed, you know, at scale, at a large bank, and you know, it’s a critical, kind of, somebody’s getting paged kind of issue, right? We have a couple of bugs like that where we need, you know, we need a couple of repros from a couple different people in a couple different situations before we can really figure out what’s going on. And having a wide user base who is happy to talk to us really helps us.

Corey: I would say it goes beyond that, too. I have—I see things in the world of Tailscale that started off as features that I requested. One of the more recent ones is, it is annoying to me to see on the Tailscale machines list everything I have joined to the tailnet with that silly little up arrow next to it of, “Oh, time to go back and update Tailscale to the latest,” because that usually comes with decent benefits. Great, I have to go through iteratively, or use Ansible, or something like that. Well, now there’s a Tailscale update option where it will keep itself current on supported operating systems.

For some unknown reason, you apparently can’t self-update the application on iOS or macOS. Can’t imagine why. But those things tend to self-update based upon how the OS works due to all the sandboxing challenges. The only challenge I’ve got now is a few things that are, more or less, embedded devices that are packaged by the maintainer of that embedded system, where I’m beholden to them. Only until I get annoyed enough to start building a CI/CD system to replace their package.

Maya: I can’t wait till you build that CI/CD system. That’ll be fun.

Corey: “We wrote this code last night. Straight to the bank with it.” Yeah, that sounds awesome.

Maya: [laugh] You’d get a couple of term sheets for that, I’m sure.

Corey: There are. I am curious, looping back to the start of our conversation, we talked about enterprise security requirements, but how do you address enterprise change management? I find that that’s something an awful lot of companies get dreadfully wrong. Most recently and most noisily on my part is Slack, a service for which I paid thousands of dollars a year, decided to roll out a UI redesign that, more or less, got in the way of a tremendous number of customers and there was no way to stop it or revert it. And that made me a lot less likely to build critical-flow business processes that depended upon Slack behaving a certain way.

Just, “Oh, we decided to change everything in the user interface today just for funsies.” If Microsoft pulled that with Excel, by lunchtime they’d have reverted it because an entire universe of business users would have marched on Redmond to burn them out otherwise. That carries significant cost for businesses. Yet I still see Tailscale shipping features just as fast as you ever have. How do you square that circle?

Maya: Yeah. I think there’s two different kinds of change management really, which is, like—because if you think about it, it’s like, an enterprise needs a way to roll out a product or a feature internally and then separately, we need a way to roll out new things to customers, right? And so, I think on the Tailscale side, we have a change log that tells you about everything that’s changing, including new features, and including changes to the client. We update that religiously. Like, it’s a big deal, if something doesn’t make it the day that it’s supposed to make it. We get very kind of concerned internally about that.

A couple of things that were—that are in that space, right, we just talked about auto-updates to make it really easy for you to maintain what’s actually rolled out in your infrastructure, but more importantly, for us to push changes with a new client release. Like, for example, in the case of a security incident, we want to be able to publish a version and get it rolled out to the fleet as quickly as possible. Some of the things that we don’t have here, but although I hear requests for is the ability to, like, gradually roll out features to a customer. So like, “Can we change the configuration for 10% of our network and see if anything breaks before rolling back, right before rolling forward.” That’s a very traditional kind of infra change management thing, but not something I’ve ever seen in, sort of, the networking security space to this degree, and something that I’m hearing a lot of customers ask for.

In terms of other, like, internal controls that a customer might have, we have a feature called ACL Tests. So, if you’re going to change the configuration of who can access what in your network, you can actually write tests. Like, your permission file is written in HuJSON and you can write a set of things like, Corey should be able to access prod. Corey should not be able to access test, or whatever it happens to be—actually, let’s flip those around—and when you have a policy change that doesn’t pass those tests, you actually get told right away so you’re not rolling that out and accidentally breaking a large part of your network. So, we built several things into the product to do it. In terms of how we notify customers, like I said, that the primary method that we have right now is something like a change log, as well as, like, security bulletins for security updates.

Corey: Yeah, it’s one of the challenges, on some level, of the problem of oh, I’m going to set up a service, and then I’m going to go sail around the world, and when I come back in a year or two—depending on how long I spent stranded on an island somewhere—now I get to figure out what has changed. And to your credit, you have to affirmatively enable all of the features that you have shipped, but you’ve gone from, “Oh, it’s a mesh network where everything can talk to each other,” to, “I can use an exit node from that thing. Oh, now I can seamlessly transfer files from one node to another with tail drop,” to, “Oh, Tailscale Funnel. Now, I can expose my horrifying developer environment to the internet.” I used that one year to give a talk at a conference, just because why not?

Maya: [crosstalk 00:27:35].

Corey: Everything evolves to become [unintelligible 00:27:37] email on Microsoft Outlook, or tries to be Microsoft Excel? Oh, no, no. I want you to be building Microsoft PowerPoint for me. And we eventually get there, but that is incredibly powerful functionality, but also terrifying when you think you have a handle on what’s going on in a large-scale environment, and suddenly, oh, there’s a whole new vector we need to think about. Which is why your—the thought and consideration you put into that is so apparent and so, frankly, welcome.

Maya: Yeah, you actually kind of made a statement there that I completely missed, which is correct, which is, we don’t turn features on by default. They are opt-in features. We will roll out features by default after they’ve kind of baked for an incredibly long period of time and with, like, a lot of fanfare and warning. So, the example that I’ll give is, we have a DNS feature that was probably available for maybe 18 months before we turned it on by default for new tailnets. So didn’t even turn it on for existing folks. It’s called Magic DNS.

We don’t want to touch your configuration or your network. We know people will freak out when that happens. Knowing, to your point, that you can leave something for a year and come back, and it’s going to be the same is really important. For everyone, but for an enterprise customer as well. Actually, one other thing to mention there. We have a bunch of really old versions of clients that are running in production, and we want them to keep working, so we try to be as backward compatible as possible.

I think the… I think we still have clients from 2019 that are running and connecting to corp that nobody’s updated. And like, it’d be great if they would update them, but like, who knows what situation they’re in and if they can connect to them, and all that kind of stuff, but they still work. And the point is that you can have set it up four years ago, and it should still work, and you should still be able to connect to it, and leave it alone and come back to it in a year from now, and it should still work and [laugh] still connect without anything changing. That’s a very hard guarantee to be able to make.

Corey: And yet, somehow you’ve been able to do that, just from the perspective of not—I’ve never yet seen you folks make a security-oriented decision that I’m looking at and rolling my eyes and amazed that you didn’t make the decision the other way. There are a lot of companies that while intending very well have done, frankly, very dumb things. I’ve been keeping an eye on you folks for a long time, and I would have caught that in public. I just haven’t seen anything like that. It’s kind of amazing.

Last year, I finally took the extraordinary step of disabling SSH access anywhere except the tailnet to a number of my things. It lets my logs fill up a lot less, and you’ve built to that level of utility-like reliability over the series of longtime experimentation. I have yet to regret having Tailscale in the mix, which is, frankly, not something I can say about almost any product.

Maya: Yeah. I’m very proud to hear that. And like, maintaining that trust—back to a lot of the conversation about security and reliability and stuff—is incredibly important to us, and we put a lot of effort into it.

Corey: I really appreciate your taking the time to talk to me about how things continue to evolve over there. Anything that’s new and exciting that might have gotten missed? Like, what has come out in, I guess, the last six months or so that are relevant to the business and might be useful for people looking to use it themselves?

Maya: I was hoping you’re going to ask me what came out in the last, you know, 20 minutes while we were talking, and the answer is probably nothing, but you never know. But [laugh]—

Corey: With you folks, I wouldn’t doubt it. Like, “Oh, yeah, by the way, we had to do a brand treatment redo refresh,” or something on the website? Why not? It now uses telepathy just because.

Maya: It could, that’d be pretty cool. No, I mean, lots has gone on in the last six months. I think some of the things that might be more interesting to your listeners, we’re now in the AWS Marketplace, so if you want to purchase Tailscale through AWS Marketplace, you can. We have a Kubernetes operator that we’ve released, which lets you both ingress and egress from a Kubernetes cluster to things that are elsewhere in the world on other infrastructure, and also access the Kubernetes control plane and the API server via Tailscale. I mentioned auto-updates. You mentioned the VS Code extension. That’s amazing, the fact that you can kind of connect directly from within VS Code to things on your tailnet. That’s a lot of the exciting stuff that we’ve been doing. And there’s boring stuff, you know, like audit log streaming, and that kind of stuff. But it’s good.

Corey: Yeah, that stuff is super boring until suddenly, it’s very, very exciting. And those are not generally good days.

Maya: [laugh]. Yeah, agreed. It’s important, but boring. But important.

Corey: [laugh]. Well, thank you so much for taking the time to talk through all the stuff that you folks are up to. If people want to learn more, where’s the best place for them to go to get started?

Maya: tailscale.com is the best place to go. You can download Tailscale from there, get access to our documentation, all that kind of stuff.

Corey: Yeah, I also just want to highlight that you can buy my attention but never my opinion on things and my opinion on Tailscale remains stratospherically high, so thank you for not making me look like a fool, by like, “Yes. And now we’re pivoting to something horrifying is a business model and your data.” Thank you for not doing exactly that.

Maya: Yeah, we’ll keep doing that. No, no, blockchains in our future.

Corey: [laugh]. Maya Kaczorowski, Chief Product Officer at Tailscale. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. This episode has been brought to us by our friends at Tailscale. If you enjoyed this episode, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment that will never actually make it back to us because someone screwed up a firewall rule somewhere on their legacy connection.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.