Screaming in the Cloud - Security in the New Normal with Ev Kontsevoy

Episode Date: September 15, 2021

About EvEv Kontsevoy is Co-Founder and CEO of Teleport. An engineer by training, Kontsevoy launched Teleport in 2015 to provide other engineers solutions that allow them to quickly access and run any computing resource anywhere on the planet without having to worry about security and compliance issues. A serial entrepreneur, Ev was CEO and co-founder of Mailgun, which he successfully sold to Rackspace. Prior to Mailgun, Ev has had a variety of engineering roles. He holds a BS degree in Mathematics from Siberian Federal University, and has a passion for trains and vintage-film cameras.Links:Teleport: https://goteleport.comTeleport GitHub: https://github.com/gravitational/teleportTeleport Slack: https://goteleport.slack.com/join/shared_invite/zt-midnn9bn-AQKcq5NNDs9ojELKlgwJUAPrevious episode with Ev Kontsevoy: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/the-gravitational-pull-of-simplicity-with-ev-kontsevoy/

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. This episode is sponsored in part by our friends at VMware. Let's be honest, the past year has been far from easy due to, well, everything.

Caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations, and headaches for everyone trying to manage disparate and fractured cloud environments. VMware has an answer for this. With VMware's multi-cloud solutions, organizations have the choice, speed, and control to migrate and optimize applications seamlessly without

recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge you to take a look at vmware.com slash go slash multicloud. You know my opinions on multicloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me. That's VMware.com slash go slash multi-cloud, all one word. And my thanks to them again for their sponsorship of my ridiculous nonsense. You could go ahead and build your own coding and mapping notification system, but it takes time,

and it sucks. Alternately, consider Courier, who's sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability, and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them that I sent you and watch them wince because everyone does when you bring up my name. That's the glorious part of being me. Once again, you could build your own notification system, but why on God's flat earth would you do that? Visit courier.com today to learn more. Welcome to Screaming in the Cloud. I'm Corey Quinn. Roughly a year ago, I had a promoted

guest episode featuring Ev Konsevoy, the co-founder and CEO of Teleport. A year has passed, and what a year it's been. Ev is back to tell us more about what they've been up to for the past year and, ideally, how things may have changed over in the security space. Ev, thank you for coming back to suffer the slings and arrows. I will no doubt be hurling your way almost immediately. Thanks for having me back, Corey. So it's been a heck of a year. We were basically settling into the pandemic when last we recorded and people's security requirements when everyone's remote were dramatically changing. A year later,

what's changed? It seems like the frantic grab a bucket and start bailing philosophy has largely been accepted with something that feels like almost like a new normal-ish. What are you seeing? Yes, we're seeing the exact same thing, that it's really hard to tell what is normal. So at the beginning of the pandemic, our company teleport was, so we were about 25 people. And then once we got the vaccines and the government restrictions started to kind of disappear, people started to ask, so when are we going to go back to normal? But the thing is, we're 100 employees now, which means that three quarters of the company, they joined us during the pandemic.

So we have no normal to go back to. So now we have to redefine, not redefine, we just basically need to get comfortable with this new, fully remote culture, with fully remote identity that we have, and become comfortable with it. And that's what we're doing. Beyond what I guess you're seeing, as far as the culture goes internally as well, it feels like there's been a distinct shift in the past year or so, the entire security industry. I can sit here and talk about what I've seen, but again, I'm all over the place, and I deal with a very select series of conversations. And I try not to confuse anecdotes with data.

Anecdata is not the most reliable thing. You're working in this space. That is the entire industry you're in. How has the conversation in the industry around security shifted? What's new? What trends are emerging? So there are several things actually happening. So first of all, I wouldn't call

ourselves like we do all of security. So we're experts in access. Like how do you access everything that you have in your cloud or in your data centers? And that space has been going through one transformation after another. It's been basically under the same scaling stress as the rest of cloud computing industry. And we can talk about historical changes that have been happening, and then we can talk a little bit about kind of latest and greatest.

And in terms of what challenges companies have with secure access, maybe it helps if I just quickly describe what access actually means. Please, by all means. It's one of those words that everyone knows, but if you ask three people to define it, you'll get five definitions, and they don't really align. So please, you're the expert on this. I am here to listen because

I guarantee you I am guilty of misusing the term at least once so far today. Can't blame you. Can't blame you. I i was same way until i got into the space so access basically means four things so if you want to have access done properly into your cloud resources you need to think about four things first is connectivity that's basically a physical ability to deliver an encrypted packet from a client to destination to a resource whatever that is could be database could be like ssh resource, whatever that is. Could be database, could be like SSH machine, or whatever it is you're connecting to. So connectivity is number one. So then you need to authenticate, authentication. That's when a resource decides if you should have access or not, based on who you are, hopefully. So then authorization, that's the third component.

Authorization, the difference, like sometimes people confuse the two, the difference between authentication and authorization is that authorization is when you already authenticate it, but the resource decides what actions you are allowed to perform. The typical example is like, is it read-only or read-write access, right? So that's authorization, deciding on which actions you're allowed to perform. And the final component of having access problem is having audit or visibility, which is, again, it could be real-time and historical. So ideally, you need to have both. So once you have those two solved, then you solved your access problem. And historically, if you look at how access has been

done, so we had these giant machines, then we had microcomputers, then we had PCs. And they all have these things. So you log in into your Mac, and then if you try to delete certain file, you might get access denied. So you see there is connectivity. In this case, it's physical. Keyboard is physically connected to the actual machine. So then you have authentication that you log in in the beginning, then authorization, if you can or cannot do certain things in your machine. And finally, your Mac keeps an audit log. But then once the industry, like we got the internet, we got all these clouds. So amount of these components that we're now operating on,

we have hundreds of thousands of servers and load balancers and databases and Kubernetes clusters and dashboards. All of these things, all of them implement these four things. Connectivity, authentication, authorization, audit. Let me drive into that for a minute first to make sure I'm clear on something. Connectivity makes sense. The network is the computer, etc. When you don't have a network to something, it may as well not exist. I get that. And the last one you mentioned, audit, of a trail of who done it and who did what when, that makes sense to me. But authentication and authorization are the two slippery ones in my mind that tend to converge a fair bit. Can you dive a little bit and delineate

what the difference is between those two, please? So authentication, if you try to authenticate into a database, database needs to check if you are on the list of people who should be allowed to access. That's authentication. You need to prove that you are who you claim you are. Do you have an account and credentials to get into that account? Correct. And there are good ways to do authentication and bad ways to do authentication. So bad way to do authentication, and a lot of companies are actually guilty of that, if you're using shared credentials. Let's say you have a user called admin, and that user has a password,

and those two are stored in some kind of stored, in like one password or something like vault, some kind of encrypted vault. And then when someone needs to access a database, they go and borrow these credentials, and they go and do that. So that is an awful way to do authentication. Another way I've seen that's terrible has been also,

oh, if you're connecting from this network, you must be allowed in, which is just me. Oh, yeah, that's a different sin. That's a perimeter security sin. But a much better way to do authentication is what is called identity-based authentication. Identity means that you always use your identity of who you are within the company. So you would go in through corporate SSO, something like Okta or Active Directory or even Google or GitHub. And then based on that information, you're given access. So the resource, in this case database, loses.

Oh, it's Cori. And Cori is a member of this group and also a member of that group. And based on that, it allows you to get in. But that's where authentication ends. And now, if you want to do something, like let's say you want to delete some data, now a database needs to check, can you actually perform that action? That is the authorization process. And to do that, usually we use a mechanism like role-based access control. It will look into which group are you in, or you are an admin. So admins have more privileges than regular people. So then that's the process of authorization. And the importance of separating the two and the importance to use identity, identity because remember audit is another important

component of implementing access properly so if you're sharing credentials for example you will see in your audit log admin did this admin did that it's exact same admin but you don't know who actually was behind that action so by sharing credentials you're also obscuring your own audit which is why it's not really a good thing. And going back to this industry trends is that because the amount of these resources like databases and servers and so on in the cloud has gotten so huge. So we now have this hardware pain. We just have too many things that need access. And all of these things, the software itself is getting more complicated. So now we have a software pain as well, that you have so many different layers in your stack that they need access.

That's another dimension for introducing access pain. And also we just have more developers. The development teams are getting bigger and bigger. The software is eating the world. So there is a people-aware pain. So on one hand, you have these four problems you need to solve. Connectivity, authentication, authorization, access. And on the other hand, you have more hardware, more software, more people. These are pain points. And so you need to consolidate. And that's really what we do, is that we allow you to

have a single place where you can do connectivity, authentication, authorization, tax, and audit for everything that you have in the cloud. We basically believe that the future is going to be like metaverse, like in those books. So all of these cloud resources are slowly converging into this one giant computer, planetary-scale computer. Suddenly, I live on Twitter is no longer going to be quite as much of a metaphor as it is today. No, no. Yeah, I think we're getting there. If you look into what is actually happening on our computing devices that we buy, the answer is not a lot. So everything is running in data centers, like the paradigm of a thin client seems to be winning.

Let's just embrace that. Yeah. You're never going to be able to shove a data center's worth of compute into a phone. By the time you can get there, data centers will have gotten better. It's the constant question of where do you want things to live? How do you want that to interact? I talk periodically about multi-cloud. I talk about lock-in. Everyone has a concern about vendor lock-in. But the thing that people tend to mostly ignore is that you're already locked in through a variety of different ways. And one way is both the networking side of it as well as the identity management piece, because every cloud handles that differently. And equating those same things between different providers that work different ways is monstrous. Is that the story of what you're approaching from a teleport perspective? Is that the primary use case? Is that an ancillary use case?

Or are we thinking about this in too small a term? So you're absolutely right. Being locked in by itself is not a bad thing. It's a trade-off. So if you lack expertise in something and you're outsourcing certain capability to a provider, then you're developing that dependency. You may call it lock-in or not, but that needs to be a conscious decision.

Like, well, you didn't know how to do it, then someone else is doing it for you, so it should be okay with the lock-in. However, there is a danger, like an industry-wide danger about everyone relying on one single provider. So that is really what we all try to avoid. And with identity specifically, I feel like we're in a really good spot that fairly early, I don't see a single provider like emerging as owning everyone's identity. You know, some people use Okta,

others totally happy tying everything to Google Apps. So then you have people that rely on Amazon, AWS native credentials, and plenty of smaller companies, they're totally happy having all of their engineers authenticate through GitHub. So they use GitHub as a source of identity. And the fact that all of these providers are more or less compatible with each other. So we have protocols like OpenID Connect and SAML. So I'm not that concerned that identity itself is getting captured by a single player. And Teleport is not even playing in that space. We don't keep your identity. We integrate with everybody. Because at the end of the day, we want to be the solution of choice for a company,

regardless of which identity platform they're using. And some of them using several, like all of the developers might be authenticating via GitHub, but everyone else goes through Google Apps, for example. And the different product problem. Oh, my stars. I was at a relatively small startup going through an acquisition at one point in my career. And all right, let's list all of the SaaS vendors that we use. And the answer was something on an average of five per employee by the time you did the numbers out. And there were hundreds of them. And most of them, because we're smarted off small, and everyone has their own individual account. We set it up there. I mean, my identity management system here for most of what I do is LastPass. I have individual accounts there, two-factor auth enabled for anything that supports it. And that is it. Some vendors don't

support that. We have to use shared accounts, which is just terrifying. We make sure that we don't use those for anything that's important. But it comes down to, from our perspective, that everything has their own ridiculous series of approaches. And even if we were to, all right, it's time to grow up and be a responsible business and go for a single sign-on approach, which is inevitable as companies scale. And there's nothing wrong with that. But there's still so many of these edge case and corner case stories that don't integrate. So it makes the problem smaller, but it's still there rather persistently.

And it doesn't even get into the fact that for a lot of these tools, oh, you want SAML integration, smells like enterprise to us, and suddenly they wind up having an additional surcharge on top of that for accessing it via a federated source of identity, which means there are active incentives early on to not do that. It's absolutely insane. Yeah, you're right. You're right. It's almost like you get penalized for being small, like in the early days. It's not that easy if you have a small project you're working on. It's a company of three people, and they're just cranking in the garage. And it's just so easy to default to using shared credentials and storing them in LastPass or 1Password. And then, interestingly, the longer you wait,

the harder it is to go back to use a proper SSO for everything. Yeah. I do want to call out that Teleport has a free and open-source community edition that supports GitHub SSO. And in order to support Enterprise SSO, you have to go to your paid offering. I have no problem with this, to be clear, that you have to at least be our customer before we'll integrate with your SSO solution makes perfect sense. But you don't have a tiering system where, oh, you want to add that other SSO thing in,

well, then it's going to go from X dollars per employee to Y dollars, which is the path that I don't like. I think it's very reasonable to say that there are features flat out you don't get as a free user. And even then, you do offer SSO, just not the one that some people will want to pick. Correct. So the open source version of Teleport supports SSO that smaller companies use versus our enterprise offering. We shaped it to be more appealing for companies at certain scale. Yeah, and you've absolutely nailed it. There are a number of companies in the security space who enrage people about how they wind up doing their differentiation around things like SSO, or God forbid, two-factor auth, or once upon a time, SSL. This is not that problem. I just want to be explicitly clear on that, that that is not what I'm talking about. But please continue.

Look, we see it the same way. We sometimes say that we do not charge for security. A top-level security you get is available even in the open source. And look, it's a common problem for most startups. Like when you have an open source offering, where do you draw the line? And sometimes you can find answers in very unexpected places. For example, let's look into a security space. One common reason that companies get compromised is, unfortunately, human factor. You could use the best tool in the world, but if you just by mistake, like, I don't know, just put a comma in the wrong place and one of your config files just suddenly is out of shape, right? So people make mistakes and you can't say never make a mistake. If you

can get your entire company compromised by someone in your office clicking on the wrong link, the solution is not to teach people not to click on links. It's to mitigate the damage and blast radius of someone clicking a link that they shouldn't. Like that is resilience that understands there are human factors at play. Yep, exactly. And here's an enterprise feature that was basically given to us by customer requests. So they would say, we want to have FedRAMP compliance

because we want to work with federal government or maybe because we want to work with financial institutions who require us to have that level of compliance. And we tell them, yeah, sure, you can configure Teleport to be compliant compliant like here's all the different things that you need to tweak in the config file and the answer is like well like what if we make a mistake it's just too costly can we have teleport just automatically works in that mode in other words if you feed it the config file with the error it will just refuse to. So basically you take your product and you chop off things that are not compliant,

which means that it's impossible to feed an incorrect config file into it. And here you've got an enterprise edition. It's a version, like we call it FIPS mode. So when it runs in FIPS mode, it has different runtime inside. It basically doesn't even have a crypto that is not approved,

which you can turn on by mistake. By the time we're talking about different levels of regulatory compliance, yeah, we are long past the point where I'm going to have any comments in the slightest about differentiation of pricing tiers and the rest. Yeah, your free tier doesn't support FedRAMP

is one of those ludicrous things. Who would say that and actually be sincere in saying that? That's just mind-boggling to me. Hold on a second. I don't want anyone to be misinformed. You can be FedRAMP compliant with a free tier. You just need to configure it properly. Like the enterprise feature in this case, like we give you a thing that only works in this mode, is impossible to misconfigure it. It's an attestation and it's a control that you need in order to demonstrate compliance, because half the joy of regulatory compliance is not doing the thing, it's proving you do the thing.

That is a joy. And those of you who've worked in regulated environments know exactly what I'm talking about, and those of you who have not are happy. But please continue. Frankly, I think anyone can do it using some other open source tool. So you can even take OpenSSH, SSHD, and then you can probably build a different makefile for it, just the build pipeline that changes the linking,

that it doesn't even have the crypto that is not on an approved list. So then if someone feeds a config file into it that has a hashing function that is not approved, it will just simply refuse to work. So maybe you can even turn it into something that you could say, like, here is a hardened version of SSHD or whatever. It's the same thing. I see now how you're talking about the four aspects of this,

the connectivity, the authentication, the authorization, and the audit components of Access. How does that map to a software product, if that makes sense? Because it sounds like a series of principles, great, and it's good to understand and hold those in your head, both separately and distinct, but also combining to mean access, both in the common parlance. How do you express that in Teleport? So Teleport doesn't really add authorization, for example, to something that doesn't have it

natively. The problem that we have is just the overall increasing complexity of computing environment. So when you're deploying something into, let's say, AWS East region, so what is it you have there? You have some virtual machines, right? Then you have something like Kubernetes on top. Then you have Docker registry. So you have these containers running inside.

Then you have maybe MongoDB. Then you might have some web UI to manage MongoDB and Grafana dashboard. So all of that is software. We're only consuming more and more of it. So our own code that we're deploying, it's icing on a really, really tall cake. And every layer in that layered cake is listening on a socket it needs encryption it has login so it has authentication it has its own idea of role-based access control it has its own config file so if you want to do cloud computing properly so you gotta have this expertise on your team how to configure those four pillars of access for every layer in your stack. That is really the pain. And the teleport value is that we're letting you do it in one place. We're saying consolidate all of these four access pillars in one location. That's really what we do. It's not

like we invented a better way to authorize or authenticate. No, we natively integrate with the cake, with all of these different layers. But consolidation, that is the key value of Teleport because we simply remove so much pain associated with configuring all of these things. Think of someone like, I'm trying not to disclose like any names of our customers, but let's pick, I don't know, like someone like Tesla, right? So Tesla has compute all over the world.

So how can you implement authentication, authorization, audit log, and connectivity to for every vehicle that's on the road, right? Because all of these things

need software updates. They're all components of a giant machine. And they're all intermittent. You can't say, oh, at this time of the road, right? Because all of these things need software updates. They're all components of a giant machine. And they're all intermittent. You can't say, oh, at this time of the day, we should absolutely make sure everything in the world is connected to the internet and ready to grab the update. It doesn't work that way. You've got to be, understand the connectivity is fickle.

So most, and because compute is growing generally, you could expect most companies in the future to be more like Tesla, so companies like that would probably want to look into teleport technology. This episode is sponsored in part by you, Gabite. Distributed technologies like Kubernetes are great, citation very much needed, because they make it easier to have resilient, scalable systems. SQL databases haven't kept pace, though. Certainly not like no SQL databases have, like Route 53, the world's database. We're still, other than that, using legacy, monolithic databases that require ever-growing

instances of compute. Sometimes we'll try and bolt them together to make them more resilient and scalable, but let's be honest, it never works out well. Consider UgaByteDB. It's a distributed SQL database that solves basically all of this. It is 100% open source, and there's no asterisk next to the open on that one. And it's designed to be resilient and scalable out of the box, so you don't have to charge yourself to death. It's compatible with Postgres SQL or Postgresqueel as I insist on pronouncing it so you can use it right away without having to learn a whole new language and refactor everything and you can distribute it wherever your applications take you from across availability zones to other regions or even other cloud providers should one of those happen to exist. Go to yugabyte.com,

that's Y-U-G-A-B-Y-T-E dot com, and try their free beta of Yugabyte Cloud, where they host and manage it for you. Or see what the open source project looks like. It's effortless distributed SQL for global apps. My thanks to you, Gabite, for sponsoring this episode. If we take a look at the four tenets that you've identified, connectivity, authentication, authorization, and audit, it makes perfect sense. It is something that goes back to the days when computers were basically glorified pocket calculators, as opposed to my pocket calculator now being basically a supercomputer. Does that change as you hit cloud scale, where we have companies that are doing what seem

to be relatively pedestrian things, but also having 100,000 EC2 instances hanging out in AWS? Does this add additional levels of complexity on top of those four things? Yes. So there is one that I should have mentioned earlier. So in addition to software, hardware, and peopleware, so those are three things that are exploding, right? More compute, more software, more engineers needing access. There is one more dimension that is kind of unique now at this scale that we're in today, and that's time. So let's just say that you are a member of a really privileged group, like you're a DBA or maybe you are like a chief security officer. So you should have access

to a certain privileged database. But do you really use that access 24-7, like all the time? No, but you have it. So like your laptop has an ability, if you type certain things into it, to actually receive credentials, like certificates, to go and talk to this database all the time. It's an anti-pattern that is now getting noticed. So the new approach to access is to make it tied to an intent. So by default, no one in an organization has access to anything. So if you want to access a database or a server or Kubernetes cluster, you need to issue what's called access request. It's similar to pull request if you're trying to commit code into Git. So you send an access request using Teleport, for example.

You could probably do it some other way. And it will go into something like Slack or PagerDuty. So your team members will see that, oh, Corey is trying to access that database. And he listed like a ticket number, like some issue he's trying to troubleshoot with that particular database instance. Yeah, we'll approve access for 30 minutes. So then you go and do that, and the access is revoked automatically after 30 minutes. So that is

this kind of new trend that's happening in our space. And it makes you feel nice too. It means that if someone hacks into your laptop at this very second, right after you finished authenticating an authorization, you're still okay because there is no access. Access will be created for you if you request it based on the intent. So it dramatically reduces the attack surface using time as additional dimension. Then a viable permission to do a thing, principal at least access, is important in these areas. It's like, oh yeah, my user account, you mean root. Yeah, I guess that works in a developer environment. Looks like a Docker container that will be done as soon as you're finished. But for most use cases, and probably even that one, that's not the direction to go in. Having things scoped down, and not just by what the provision

is, but by time. Exactly. This system basically allows you to move away from root-type accounts completely for everything. So which means that there is no root to attack anymore. What really strikes me is how many different aspects of technology that this winds up getting to. And to illustrate that in the form of a question, let me go back to my own history because, you know, let's make it about me here. I've mentioned it before in this show, but I started off my technical career as someone who specialized in large-scale email systems. That was a niche I found really interesting and I got into it. So did you. I worked on running email servers and you were the CEO and co-founder of Mailgun, which later you sold to Rackspace. You're a slightly bigger scale than I am, but it was clear to me that even then, in the 2006 era when I was doing this, that there was not going to be the same need going forward for an email

admin at every company. The cloudification of email had begun, and I realized I could either dig my heels in and fight the tide, or I could find other things to specialize in. I've told that part of the story. But what I haven't told is that it was challenging at first as I tried to do that, because all the jobs I talked to looked at my resume and said, ah, you're the email admin. Great. We don't need one of those. It was a matter of almost being pigeonholed or boxed in to the idea of being the email person. I would argue that teleport is not synonymous with email in any meaningful sense as far as how it is perceived in the industry. You are very clearly no longer the email guy. Does the idea of being boxed in, I guess, resonate at all with you? And if so,

how did you get past it? Absolutely. The interesting thing is before starting Mailgun, I was not an email person. I would just say that I was just general purpose technologist and I always enjoyed building infrastructure frameworks. Basically, I always enjoyed building tools for other engineers, but then gotten into this email space. And even though Mailgun was a software product, right, which actually had surprisingly huge kind of scalability requirements early on, because email is much heavier than HTTP traffic. People just send a lot of data via emails.

So we were solving interesting technical challenges. But when I would meet other engineers, I would experience the exact same thing you did. They would put me into this box. I'm like, that's an email guy. He knows email technology, but seemingly doesn't know much about scaling web apps, which was totally not true. And it bothered me

a little bit. Frankly, it was one of the reasons we decided to get acquired by Rackspace because they effectively said, why don't you come join us and MailGal will continue to operate as an independent company, but you can join our cloud team and help us reinvent cloud computing. It was really appealing.

So I actually moved to Texas after acquisition. I worked on the Rackspace cloud team for a while. So that's how my transition from this being in the email box happened. So I went from an email expert to just generally cloud computing expert. And cloud computing expert sounds awesome. And it allows me to work. I promise it's not awesome, people listening to this. Also, it's one of those, are you a cloud expert? Everyone says no to that because who in the world would claim that? It's so broad and so many different expressions of it. Because you know, the follow-up question to anyone who says,

yes, it's going to be some esoteric thing about a system you've never heard of before, because there are so many ridiculous services across so many different providers. Of course, that's probably a thing. Maybe it's actually a Pokemon. We don't know. But it's hard to consider yourself an expert in this. It's like, well, I have some damage from getting smacked around by clouds. And yeah, we'll call that expertise. Why not? Exactly. And also how frequently people mispronounce like cloud with clown. It's like, oh, I'm clown computing expert. People mostly call me a loud computing expert, but that's a separate problem. But the point is that if you work on a product that's called cloud, right? So you definitely

get to claim expertise of that. And the interesting thing that Mailgun being effectively an infrastructure level product, so it's part of the platform, like every company built their own cloud platform and runs on it, so Teleport is part of that. So that allowed us to get out of the box. So if you're working on, right now we're in the access space, so we're working closely with Kubernetes community, with Linux kernel community, with databases. So by extension, we have expertise in all of these different areas.

And it actually feels much nicer. So if you're a computing security access company, people tend to look at you like, yeah, you know a little bit of everything. So that feels pretty nice. It's one of those cross-functional things. Whereas on some level, you just assume, well, email isn't either. But let's face it, email is the default API that everything. There's very little that you cannot configure to send email.

The hard part is how to get them to stop emailing you. But it started off, as far as, for my world at least, the idea that all roads lead to email. In fact, we want to talk security. A long time ago, the internet collectively decided one day that our email inbox was the entire cornerstone of our online identity. Give me access to your email. I, for all intents and purposes, can become you on the internet without some serious controls around this. So those conversations, I feel like they were heading in that direction by the time I left the email world. But it's very clear to me that what you're doing now at Teleport is a much clearer ability to cross

boundaries into other areas where you have to touch an awful lot of different things, because security touches everything. And I still maintain it has to be baked in an intentional thing rather than, oh yeah, we're going to bolt security on after the fact. It's, yeah, you hear about companies who do that usually in headlines about data breaches or worse. It's a hard problem. Actually, it's an interesting dilemma you're talking about. Is security built in into everything, or is it an add-on? And logically, I talk to anyone, and most people say, yeah, it needs to be just

core component of whatever it is you're building. Making security as an add-on is not possible. But then reality hits in. And reality is that we're standing on the shoulder of giants. There are so many, so much legacy technologies that we built this cloud monster on top of. No, nothing was built in. So we actually need to be very crafty at adding security on top of what we already have if we want to take advantage of all these pre-existing things that we've built for decades. So that's really what's happening, I think, with security and access. So if you ask me if Teleport is a bolt-on security,

I'd say, yes, we are. But it works really well. And it's extremely pragmatic and reasonable and gives you security compliance, but most of all, very, very good user experience out of the box. It's amazing to me how few security products focus on user experience out of the box. It's amazing to me how few security products focus on user experience out of the box, but they have to. You cannot launch or maintain a security product successfully, to my mind, without making it non-adversarial to the user. The days of security is no, they're gone. Because of that human element in security. If you make something complicated, if you make something that's hard to reason about, then it will never be secure.

Yeah. Don't copy-paste IP table rules without understanding what they do. Yeah, I think we all have been around long enough in data center universes. Remember those middle-of-the-night drives to the data center for exactly that sort of thing? Yeah.

It's one of those hindsight things. Set a cron job to reset the IP table rules for, you know, 10 minutes from now, in case you get this hilariously wrong. It's the sort of thing that you learn right after you really could have used that knowledge. Same story. But those are the easy, safe examples of, I screwed up on a security thing. The worst ones can be company ending. Exactly, yeah. So in this sense, when it comes to security and access specifically,

this old Python rule that there is only one way to do something, it's the most important thing you can do. So when it comes to security and access, it's one of the things that Teleport has designed around, that for all protocols, for all different resources, from SSH to Kubernetes to web apps to databases, we never support passwords. It's not even in a code base. Like, no, you cannot configure Teleport to use passwords. We never support things like public keys, for example, because it's just another form of a password. It's just extremely long password. So we have this approach that certificates, it's the best method because it supports both authentication and authorization. And then you have to do it for everything,

just one way of doing everything. And then you apply this to connectivity. So there is a single proxy that speaks all protocols and everyone goes to that proxy. Then you apply the same principle to audit. There is one audit where everything goes into. So that's how this consolidation, that's where this simplicity comes down to. So one way of doing something, one way of configuring everything. So that's where you get both ease of use and security at the same time. One last question that I want to ask you

before we wind up calling this an episode is that I've been using Teleport as a reference for a while when I talk to companies generally in the security space as an example of what you can do to tell a story about a product that isn't built on fear, uncertainty, and doubt. And for those who are listening and don't know what I'm referring to specifically, I'm talking about picking a random security company and pull up their website and see what it is that they talk about and how they talk about themselves. Very often, you'll see stories where data breaches will cost you extraordinary piles of money, or

they'll play into the shame of what'll happen to your career if you're named in the New York Times for being the CISO when the data gets breached and whatnot. But everything that I've seen from Teleport to date has instead not even gone slightly in that direction. It talks again and again in what I see on your site about how quickly it is to access things, access that doesn't get in the way, easily implement security and compliance, visibility into access and behavior. It's all about user experience and smoothing the way and not explaining to people what the dire problems that they're going to face are if they don't care about security in general and buy your

product specifically. And it is, it is such a refreshing way of viewing storytelling around a security product. How did you get there? And how do I make other people do it too? I think it just happened organically. Teleport originally, the interesting story of Teleport, it was not built to be sold. Teleport was built as a side project that we started for another system that we were working on at the time. So there was an autonomous Kubernetes platform called Grite. It doesn't really matter in this context, but we had this problem that we had a lot of remote sites with a lot of infrastructure on them with extremely strict security and compliance requirements, and we needed to access those sites or build tools to access those sites

so teleport was built like okay it's way better than just stitching a bunch of open source components together because it's it's faster and easier to use so we were optimizing for that and the side effect of that simplification consolidation and better user experience is security compliance and then the interesting thing that happened is that people who were trying to sell the big platform to, they started to notice, but oh, like this access thing you have is actually pretty awesome. Can we just use that separately? And that's how it turned into a product. So we built an amazing secure access solution almost by accident because there was only one customer in mind and that was us in the early days. So yeah, that's how you do it, basically.

But it's surprisingly similar to Slack, right? Why is Slack awesome? Because the team behind it was a gaming company. They started building a game. Yeah, they built it for themselves. I guess that's the trick. Make yourself happy. I think the team founded Flickr before that, and they were trying to build a game.

And the joke I heard is like, all right, the year is 2040. Stuart and his team have now raised $8 billion trying to build a game. And yet again, it fails upward into another productivity tool company or something else entirely that, but it's a recurring pattern. Someday they'll get their game made. I have faith in them. But yeah, building a tool that scratches your own itch is either a great path or a terrible mistake, depending entirely

upon whether you first check and see if there's an existing solution that solves the problem for you. The failure mode of this is, ah, we're going to build our own database engine in almost every case. Yeah. So just kind of like interesting story about the two. People often surprise that Teleport is a single binary. It's basically a drop-in replacement that you put on a box and it runs instead of SSHD. But it wasn't initially this way. Initially, it was like a few files in different parts of a file system.

But because internally, I really wanted to run it on a bunch of Raspberry Pis at home. And it would have been a lot easier if it was just a single file because then you just could quickly update them all. So it just took a little bit of effort

to compress it down to a single binary that can run in different modes depending on the key. And now look at that. It's a major benefit that a lot of people who deploy Teleport on like hundreds of thousands of pieces of infrastructure, they're definitely taking advantage of the fact that it's that simple. Simplicity is the only thing that scales. As soon as it gets complex, there's more things to break. Ev, thank you so much for taking the time to sit with me yet again to talk about Teleport and how you're approaching things. If people want to learn more about you, about the company,

about the product in all likelihood, where can they go? The easiest place to go would be goteleport.com, where you can find everything, but we're also on GitHub. If you search for Teleport on GitHub, you'll find us there. So join our Slack channel, join our community mailing list, and most importantly, download Teleport, put it on your Raspberry Pi, play with it, and see how awesome it is to have the best industry, best security practices that don't get in the way. I love the tagline. Thank you so much once again. Ev Koncevoy, co-founder and CEO of Teleport. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, 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 a comment that goes into a deranged rant about how I'm completely wrong, and the only way to sell security products, specifically yours, is by threatening me with the New York Times data breach story. 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.

This has been a HumblePod production. Stay humble.