 The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain and KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend along with Paul Gillan, Senior Editor, Enterprise Architecture at SiliconANGLE. We are talking to some incredible folks this week, continuing the conversation around enabling developers to do their work. Paul, you've said that this conference is about developers. What are you finding key as a theme running throughout the show? That developers really need a whole set of special tools. It's not the end user tools, the end user access controls, the authentication. Developers need to live in their own environment. They need their own workflow tools, their own collaboration and their own security and that's where Teleport comes in. So speaking of Teleport, we have Michael Farenti, Chief Marketing Officer at Teleport, new world role for you. First, tell me about how long have you been at Teleport now? Going on seven or eight months now. Seven or eight months in this fast moving market. I'm going to tell you a painful experience I've had in this new world. We've built applications, we've moved fast, auditors come in, the auditors have come in and they say, you know what, who authorized this change to the cluster? And we'll go into the change ticket and say this person authorized the changes and the change ticket and then they'll ask for trace back, okay, show me the change. What do you mean show you the changes? It just happened. Yeah, check GitHub. Yeah, check, see, we said we were going to make the changes and the change happened. That's not enough. What are, how are you helping customers solve this access control and audit problem? Yeah, that's a great question. They're kind of two sides of the puzzle and actually I think the intro hits it well. You've talked about kind of developer experience needing tools to more efficiently do the job as a practitioner and you're coming at it from kind of a security and compliance angle and there's a tension between both of those teams. It's like, you know, there's a tension between Dev and Ops before we created DevOps. There's also a tension between kind of security teams and developers so we've created DevSecOps. What that means is you need an easy way for developers to get access to the resources they need to do their jobs. That's, you know, Linux hosts and databases and Kubernetes clusters and, you know, monitoring dashboards and managing all of those credentials is quite cumbersome. If I need to access a dozen systems, then, you know, I'm using SSH keys to access this. I have admin credentials for my database. I'm going through a VPN to access an internal dashboard. Teleport consolidates all of that access into a single login via your identity provider, Octa Active Directory. But then on the security and compliance side, we make it really easy for that compliance offers when they say, show me that change. We have all of the audit logs that show exactly what changes Keith made when he logged into that system. And in fact, one of the booths behind here is talking about EBPF, a modern way to get that kind of kernel level granularity. We built all of that observability into Teleport to make the security and compliance teams happy and the engineering teams a lot more productive. Where do the access control tools like Octa, you mentioned fall short? I mean, why is there a need for your level of control at the control plane? Yeah, when you start to talk about authorization, authentication, audit at the infrastructure level, each of these technologies has its own way of managing what kind of in the jargon, authentication, authorization. So you have SSH for Linux, Kubernetes has its own way of doing authorization, all of the database providers have their own way. And it's quite complicated, it's much different. So if I want to access Office 365 or I want to access Salesforce, I'm really talking about the HTTP protocol. It's relatively trivial to implement single sign-on for web-based applications, but when we start talking about things that are happening at the Linux kernel level or with Kubernetes, it's quite complicated to build those integrations. I mean, that's where Teleport extends what you have with your IDP. So for instance, Octa, lots of our customers use Octa as their identity provider, but then Teleport takes those roles and applies them and enforces them at the actual infrastructure level. So if I'm a lay developer, I'm looking at this thinking, you know, I have service mesh, I've implemented LinkerD, SEO or something to that level, and I also have Ansible. And Ansible has security, et cetera. What role or how does that integrate all together from a big picture perspective? Yeah, so one of the kind of the meta themes that Teleport is we like to say that we were fighting complexity because as we build new technologies, we tend to run the new tech on top of the old tech, whereas for instance, when you buy a new car, you typically don't, you know, hook the old car to the back and then pull it around with you, right? We replace old technology with new technology, but in infrastructure, that doesn't happen as often. And so you end up with kind of layers of complexity with one protocol sitting on top of another protocol on top of another protocol. And what Teleport does is for the access control plane, we kind of replace the legacy ways of doing authentication, authorization and audit with a new modern experience, but we allow you to continue to use the existing tools. So we don't replace, for instance, you know, your configuration management system. You can keep using Ansible or Salt or Jenkins, but Teleport now is going to give those scripts or those pipelines an identity that you can define what should Ansible be able to do, right? Because people are worried about supply chain attacks if a vulnerable dependency gets introduced into your supply chain pipeline and your kind of Ansible playbook goes crazy and starts deploying that vulnerability everywhere, that's probably something you want to limit. With Teleport, you can limit that with an identity, but you can still use the tools that you're used to. So how do I guarantee something like an ex-employee doesn't come in and initiate Ansible script that was sitting in the background, just waiting to happen until they left? Yeah, great question. There's kind of the great resignation that's happening. We did a survey where actually, we asked the question kind of, can you guarantee that ex-employees can no longer access your infrastructure? And shockingly, like 89% of companies could not guarantee that. It's like, wow, that should be a headline somewhere. And we actually just learned that there are on the dark web, there are people that are targeting current employees of Netflix and Uber and trying to buy credentials of those employees to the infrastructure. So it's a big problem. With Teleport, we solve this in a really easy, transparent way for developers. Everything that we do is based on short-lived certificates. So unlike a SSH key, which exists until you decommission it, short-lived certificates, by default, expire. And if you don't re-issue them based on a new login, based on the identity, then you can't do anything. So even a stolen credential, kind of its value decreases dramatically over time. So that's statistic where four out of five companies can't guarantee ex-employees can't access infrastructure. Why is simply removing the employee from the old app or decommissioning their login credentials? Why is that not sufficient? Well, it depends on if everything is integrated into your identity provider. And because of the complexities of accessing infrastructure, we know that developers are creative people. And by definition, they're able to create systems to make their lives easier. So one thing that we see developers doing is kind of copying an SSH key to a local notepad on their computer. So they essentially can take that credential out of a vault. They can put it somewhere that's easier for them to access. And if you're not rotating that credential, then I can also copy it to a personal device as well. Same thing for shared admin credentials. So the issue is that those credentials are not completely managed in a unified way that enables the developer to not go around the system in order to make their lives easier, but rather to actually use the system. There's a market called Privilege Access Management that a lot of enterprises are using to kind of manage credentials for their developers, but it's notoriously disruptive to developer workflows. And so developers kind of go around the system in order to make their jobs easier. What Teleport does is we obviate the need to go around the system, because the simplest thing is just to come in in the morning, log in one time to my identity provider, and now I have access to all of my servers, all of my databases, all of my Kubernetes clusters with a short-lived certificate that's completely transparent. Does this apply to both your local and your cloud accounts? Yes, yes, exactly. So as a security company, what's driving the increase in security breaches? Is it the lack of developer hygiene? Is it this ex-employee, great resignation bill? Is it external intruders? What's driving security breaches today? Yes, it's all of those things. I think if I had to give you a one-word answer, I would say complexity. The systems that we are building are just massively complex, right? Look at how many vendors there are at this show in order to make Kubernetes easy to use to do what its promise is. It's just, we're building very complex systems. When you build complex systems, there's a lot of back doors. We call it kind of attack surface. And that's why for every new thing that we introduce, we also need to think about, how do we remove old layers of the stack so that we can simplify, so that we can consolidate? It take advantage of the power of something like Kubernetes without introducing security vulnerabilities. One of the problems or challenges with security solutions is, there's this complexity versus flexibility knob that you need to be careful of. What's the deployment experience and integration experience for deploying teleport? Yeah, we built it to be cloud native, to feel like any other kind of cloud native or Kubernetes-like solution. So you basically, you deploy it using a help chart. You deploy it using containers. And we take care of all of the auto configuration and auto update so that it's part of your stack and you manage it using the same automation that you use to manage everything else. That's a big kind of installation and developer experience part of it. If it's complex to use, then not only are developers not going to use it, operations teams are not going to want to have to deal with it, and then you're left with doing things the old way, which is very unsatisfactory for everybody. How does Kubernetes change the security equation? Are there vulnerabilities it introduces to the stack that maybe companies aren't aware of? Almost by definition, yes. Kind of any new technology is going to introduce new security vulnerabilities. That is the result of the complexity, which is there are things that you just don't know when you introduce new components. I think kind of all of the supply chain vulnerabilities are a way of looking at that, which is we have Kubernetes as itself built on a lot of dependencies. Those dependencies themselves could have security vulnerabilities. You might have a package that's maintained by one kind of hobbyist developer, but that's actually deployed across hundreds of thousands of applications across the internet. So again, it's about one understanding that that complexity exists and then saying, is there a way that we can kind of layer on a solution that provides a common layer to let us kind of avoid that complexity and say, okay, every critical action needs to be authorized with an identity. That way, if it's automated or if it's human, I have that level of assurance that a hacked Ansible pipeline is not going to be able to introduce vulnerabilities across my entire infrastructure. So one of the challenges for CIOs and CTOs is the lack of developer resources. And another resulting pain point that compounds that issue is reworked due to security audits. Is teleport a source of truth that when a auditor comes in to audit a CI CD pipeline that the developer or operations team can just say, hey, here's self-service, get what you need and come back to us with any questions. Or is there a second set of tools we have to use to get that audit and compliance report? Yeah, teleport can be that single source of truth. We can also integrate with your other systems. So you can export all of the what we call access logs. So every behavior that took place, every query that was run on the database, every curl command that was run on a Linux host, teleport is creating a log of that. And so you can go in and you can filter and you can view those actions within teleport. But we also integrate with other systems that people are using. You have a Splunk or Datadog or whatever other tool chain. It's really important that we integrate, but you can also use teleport as that single source of truth. So you can work with the observability suites that are now being installed. Yeah, the wonderful thing about kind of an ecosystem like Kubernetes is there's a lot of standardization. You can pick your preferred tool, but under the hood, the protocols for taking a log and putting it in another system are standardized. And so we can integrate with any of the tools that developers are already using. So how big is teleport? When I'm thinking about it, from a couple of things, big as in what's the footprint and then from a developer operations team overhead, is this kind of a set it and forget it? How much care, feed and maintenance does it need? So it's very lightweight. We basically have kind of two components. There's the access proxy that sits in front of your infrastructure. And that's what enables us to, regardless of the complexity that sits across your multi data center put print, your traditional applications running on Windows, your modern applications running on Linux and Kubernetes, we provide seamless access to all of that. And then there's an agent that runs on all of your hosts. And this is the part that can be deployed using your helm or any other kind of cloud native deployment methodology that enables us to do the granular application level audit. For instance, what queries are actually being run on CockroachDB or on Postgres. What CIS calls are running on Linux kernel. Very lightweight. Automation can be used to install, manage, upgrade all of it. And so from an operations perspective, kind of bringing in teleport shouldn't be any more complicated than running any application on a container. That's the design goal and what we built for our customers. If I'm in a hybrid environment, I'm transitioning and making the migration to teleport. Is this a team, is this a solution that sits only on the Kubernetes cloud native side or is this something that I can transition to initially and then migrate all of my applications to as I transition to cloud native? Yep, there are no cloud native dependencies for teleport. Meaning if you are, you're 100% Windows shop, then we support, for instance, RDP. That's the way in which Windows handles room and access. If you have some applications that are running on Linux, we can support that as well. If you've got kind of the complete opposite in the spectrum, you're doing everything cloud native, containers, Kubernetes, everything, we also support that. Well, Michael, I really appreciate you stopping by sharing the teleport story. Security is becoming an obvious pain point for cloud native and container management and teleport has a really good story around ensuring compliance and security. From Valencia, Spain, I'm Keith Townsend along with Paul Gillan and you're watching the Q, the V-Leader, not the V-Leader in high tech coverage.