Screaming in the Cloud - How Tailscale Builds for Users of All Tiers with Maya Kaczorowski

Episode Date: December 19, 2023

Maya Kaczorowski, Chief Product Officer at Tailscale, joins Corey on Screaming in the Cloud to discuss what sets the Tailscale product approach apart, for users of their free tier all the way to enterprise. Maya shares insight on how she evaluates feature requests, and how Tailscale’s unique architecture sets them apart from competitors. Maya and Corey discuss the importance of transparency when building trust in security, as well as Tailscale’s approach to new feature roll-outs and change management.About MayaMaya is the Chief Product Officer at Tailscale, providing secure networking for the long tail. She was mostly recently at GitHub in software supply chain security, and previously at Google working on container security, encryption at rest and encryption key management. Prior to Google, she was an Engagement Manager at McKinsey & Company, working in IT security for large enterprises.Maya completed her Master's in mathematics focusing on cryptography and game theory. She is bilingual in English and French.Outside of work, Maya is passionate about ice cream, puzzling, running, and reading nonfiction.Links Referenced: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 

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. 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 Kachorowski, Chief Product Officer at Tailscale. Maya, thanks for joining me. Thank you so much for having me. I have to say, originally I was a little surprised. 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. Thank you so much. Yeah, it's exciting.

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? Yeah, I don't know if you, I feel like you're talking about the product, but also the sales cycle of talking, working with enterprise customers. The product, the sales cycle, the marketing aspect of it, and it all ties together. It's different facets of, frankly, the same problem. 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. It'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 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 assurances and controls around making sure that that's not the case. 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, OK, 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. Yeah, for sure. And I think you need to balance to your point kind of creating demand for the product. It's actually solving the problem that the customer has versus checking boxes. I think about them as features or feature requests versus feature blockers or deal block, or adoption blockers. So somebody wants to, say, connect to a 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 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 an advent of some of these other companies in the 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. I think that there's a definite broadening of the use case. And I've been trying to avoid it it but let's go diving right into it i used to view tail scale 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 tail scale 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 re-evaluate 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. Well, I sure hope I'm not the official description. I think the closest is a little bit of what you were 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 the 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 a 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. 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,

and for 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. Yeah, just looking at it at a moment, I have a bunch of raspberries pie, perhaps hanging out on my tail net. 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, I think, canary hanging out on there to detect if anything starts going ridiculously weird by following 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'll surprise me at one point or another down the road. I mean, I even have an exit note 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. Oh, yeah.

I worked at a bank maybe 10 years ago, and they would block this bank on the bank on the east coast of the U.S., they would block connections from Hawaii. Because why would any of your customers ever be in Hawaii? And it was like, people travel. How can you go to Hawaii? You don't have a passport. People travel. They still need to do banking. It doesn't change. The internet, we've built a lot of weird controls that are IP-based 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. 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 at Tailscale Up, 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? 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. 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 Cori at 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 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 was 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 tail net 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 an open source. 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 i mean you also have taken significant architectural steps to ensure that you are not placed in an at a position of undue trust around a lot of these things most recently you raised a series b that was a hundred million dollars and the fact that you have not gone bankrupt in the years 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 slap and tickle with Wireshark has affirmed 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 aren't in the position of being a global observer in a way that can be, in many cases, exploited. 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-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 Skull and

it's not, you know, hairpinning, 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 plan 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 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 POCing 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.

When the network is down, the computers all turn into basically space heaters. Yeah, as long as they're not down because they're, I guess, unplugged or something. But yeah, 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 it 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, tail net 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, what new features are coming out, and you can trust us to be part of your network, to be part of your infrastructure. I want to further call out that you have a, how should I frame this, a typically active security notification page. 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 ooh, 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, ah, so it turns out that we thought was encrypting actually was it, 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? 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 you should try to catch them early in the development process, shift left and all that kind of stuff. But some things are always going to happen. 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 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 bolt-ins 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. 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 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 this 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. Yeah, I think 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 committing to doing that, if that makes any sense. I remember having a conversation many years ago with an engine

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 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 this 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 Mac OS 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. I am not a tailscale customer. And that bugs me because until I cross that chasm into transferring a dollar 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 have ever 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.

Yeah, understood. I think that you still provide value to us in ways that aren't your data, but then 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 sonology, 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, product-led growth product. 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're right in support and you find something that nobody else has found yet. I am very good at doing that entirely by accident. 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, 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 of different people in a couple of 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. 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 of 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 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 CICD system to replace their package. I can't wait till you build that CICD system. That'll be fun. We wrote this code last night straight to the bank with it.

Yeah, that sounds awesome. We can get a couple of term machines for that, I'm sure. There are. I am curious, looking 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 pay 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? 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 tail scale 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 in that space, right? We just talked about auto updates, so making 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, although I hear requests for, is the ability to gradually roll out features to a customer.

So can we change the configuration for 10% of our network and see if anything breaks before rolling back, before rolling forward? That's a very traditional kind of infratransit 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 permissions file is written in huge JSON and you can write a set of things like Cori should be able to access prod. Cori 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, the primary method that we have right now is something like a change log, as well as security bulletins for security updates. Yeah, it's one of the challenges at 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 spend 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, ooh, I can use an exit node from that thing. Oh, now I can seamlessly transfer files from one node to another with TailDrop to, oh, TailScale Funnel. Now I can expose an exit node from that thing. Oh, now I can seamlessly transfer files from one node to another with TailDrop 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? Everything evolves to become, you can send email in Microsoft Outlook or it 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 the thought and consideration you put into that is so apparent and so, frankly, welcome. 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 defaults. They're opt-in features. We will roll out features by defaults 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 it 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 we still have clients from 2019 that are running and connecting to a corp that nobody's updated. And it'd be great if they would update them,

but 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 still connect without anything changing. That's a very hard guarantee to 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 tail net to a number of my things. That's my logs fill up a lot less, and you've built to that level of utility-like reliability over the series of long-time

experimentation. I have yet to regret having tailscale in the mix, which is, frankly, not something I can say about almost any product. Yeah, I'm very proud to hear that. And 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. 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've gotten missed? 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? I was hoping you were going to ask me what came out in the last 20 minutes while we were talking, and the answer is probably nothing, but you never know. With you folks, I wouldn't doubt, 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. 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 and other infrastructure, and also access the Kubernetes control plane,

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. Yeah, that stuff is super boring until suddenly it's very, very exciting. And those are not generally good days. Yeah, agreed. It's important, but boring. But important. 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? Tailscale.com is the best place to go. You can download Tailscale from there, get access to our documentation, all that kind of stuff. I also just want to highlight that you can buy my attention, but never my opinion on things. And my opinion of Tailscale remains stratospherically high.

So thank you for not making me look like a fool, but like, yes, and now we're pivoting to something horrifying as a business model and your data. Thank you for not doing me look like a fool, but like, yes, and now we're pivoting to something horrifying as a business model and your data. Thank you for not doing exactly that. Yeah, we'll keep doing that. No blockchains in our future. Maya Kachorovsky, 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.