 Live from San Diego, California, it's theCUBE. Covering KubeCon and CloudNativeCon, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome back, this is theCUBE's coverage of KubeCon, CloudNativeCon 2019 in San Diego, 12,000 in attendance. I'm Stu Miniman, my co-host is John Troyer and I want to welcome to the program the co-founder and CTO of Lacework, Vikram Kapoor. Thank you so much for joining us. Glad to be here. So we had your CEO on at the first cloud security show earlier this year. Security, definitely, you know, it's a board-level discussion, front and center. I can never pass up the opportunity when I have a founder on the program. Just step us back for a second, kind of the why of Lacework. Yeah, yeah. So I think if you look at the cloud ecosystem and communities now with containers, it's very clear that it requires like a new kind of way to look at security. Like all the traditional security tools for the data center were really built for like, you know, based on network. And then since, you know, and as you move to the cloud, you know, it's very hard to take a hardware box to the cloud, you know, even with the virtual, you know, boxes, it's really not that clean and a good architecture. So what we found was that, you know, you really need a new way to think about it. And we think about it as really a big data problem. You collect a lot of data, you process it, you analyze it, you get people compliance and governance and breach detection automatically without having them like necessarily a lot of rules. Yeah, there's a term at this show, cloud native. And the maturity I've heard this year is some people say, when I do cloud native, that means I like bake it into Kubernetes and that means, you know, I could take my database across all the environments, I can take them there. Does that line up with how we should think about cloud security or is it more a little bit different than that? So actually it's a little bit different than that. And the reason being that, so if you do all that, the what cloud native typically would also bring with itself would be things like your VMs and containers are not long running, they're short learning. Like in the old world, I've been developing for 20 years, I knew the IP address of my database and it didn't change and I knew the port number. But now if you ask me on cloud native environments, where is my database? Like I don't know, there are five instance running and they're here and there. So there's a lot of elasticity, dynamic stuff that comes along with a network layer is not relevant at all to what the applications are doing. So you need to get into the application layer and therefore security becomes a little bit different in that environment. So it's kind of the fact that I can run like thousand containers for Node.js in like an instance, which Kubernetes allows me to do that, also means that I have no idea where they're running and what the IPs are and I don't know security on IP, I do it on Node.js. Like that's really what it is. So with Lacework though, you're really monitoring this. It's a platform, it's watching in real time, all this data is coming in. So it's both analyzing the history and it's got the stuff coming in. So you have a multiple layers. I mean, we're here at KubeCon, Kubernetes is kind of the engine of what's going on, but there are other layers going on here. There's all the application code and the pods, there's the cloud underneath, and you all support different public clouds and on-prem and things like that. Can you talk a little bit about maybe what's, some of the patterns of things you are dealing with, with all those different layers in those environments? Yeah, so I think it's actually a very relevant question. Like, if you're going to think about Kubernetes, and as you said, nothing really runs in isolation, right? Kubernetes has to use containers at some level. It has to run in either, even if it's managed, it's running in some VM somewhere, and the VM is basically either cloud native on VMware or it's hosted on some AWS cloud account, and that cloud account probably has an API access to you to be able to set these things up or unset them if an attacker gets access to that. So we kind of think of security as comprehensively doing across the board, like starting from like, you know, build environments to run environments where, before a developer does a build, you want to do one everyday analysis and make sure you're not building something with known problems in there. So you fix them as you go. Once you deploy them, you need to look at like cloud configuration and, you know, buckets are not open or security groups are not, you know, incorrect. And then beyond that, you actually really need a breach detection system, which kind of tells you when something does go wrong. And that can't be, you know, just inside Kubernetes or just containers. You kind of have to go look at every layer because, you know, I've seen it personally, like, you know, when I look at some of the attacks, like, when an attacker gets into one layer, he'll move into any layer he wants. Like, there is really no way to say, I'll isolate him in this layer only. So you have to kind of protect everything and you have to do breach detection across the board. Yeah, I remember, I feel like it was a couple of years ago, there was a security issue inside of Kubernetes. Yeah. The community freaked out a little bit, but, you know, it ended up moving past that. What are really kind of those security risks inside Kubernetes and where does, where does lace work fit into that discussion? Yeah, so I think it's really around like, you know, thinking like, you know, not Kubernetes as an isolated platform, but actually part of the tech stack and ecosystem and looking at holistically across it. So fundamentally, some of the security concepts haven't changed. You need to make sure you don't leave doors open, right? So if I have a door open on my, you know, API level, well, it doesn't really matter if I close it on Kubernetes, it's going to get exploited. Kubernetes also comes with its own API server, so that you have to monitor that also. It has its own pods and it has its own pod policies, so you're going to have to figure that too. So fundamentally, I think at some level, it boils down to making sure you kind of work with it, like security and DevOps need to work together to make sure that before they deploy it, it's kind of architected the right way. It has, you know, the correct VPCs and the pod policies and the pod architecture. And at the same time at runtime, make sure you're monitoring it so that if something happens, you know about it early, versus like six months later when the data is leaving your data center and then somebody tells you it's leaving it, like it's too late at that point. With your customers then, you're still seeing a role for the security team in the enterprise as well as the DevOps team better be coordinated with a platform like Laceware. Maybe talk a little bit about the enterprise situation and I'm guessing versus a startup, there's a lot more, there's a few other requirements that are coming to the table. Actually, we see that a lot across our customers, like fundamentally DevOps and security really have to be on the same page, because at the end of the day, like, you know, the way the cloud happened and the Kubernetes happened, it's a very API centric world. Like everything I do on AWS or GCP Azure or Kubernetes is through an API. So it's a developer kind of centric world and then if I have to set up a VPC, I have to work with DevOps to set it. If I have to set up security groups, I have to work with DevOps to set it. So fundamentally, if they're not on the same page, you end up with like, you know, having problems. So the way we help in that environment is that we are able to get security and the DevOps team on the same page, where security can understand about applications, they can look at the behavior, they can understand, you know, what the architecture is, and when they go tell DevOps to kind of, you know, there is something going on, can you help me? They can have a shared vocabulary and a language and they can talk about things like, on this part, I saw access to this website, a DNS name, not that somebody in your data center went to that IP and like, okay, but what does that mean? The container is gone and the part's gone, like, what do I do with it? So I think we see that and I see, I feel long-term, it's really a collaboration where security brings to the table a lot of the know-how and how to secure something, but at the same time, an actual implementation of it probably belongs in DevOps, where like, if you want to enforce something, you probably have to work with Kubernetes and Kubernetes APIs to actually enforce it. So it kind of goes both ways. All right, Vikram, talk to us about scale. We've talked everything from broad scale to small scale in this environment. Give us the security aspect of that. Yeah, so scale has been one of my favorite topics in the last 20 years, I've worked on disparate systems and big data, like at Oracle for a long time and fundamentally what happens is that when you do something on 10 VMs and you look at some alert, it's actually one problem, but when you scale that up to like 10,000 VMs or 10,000 containers and lots of users and developers doing multiple changes a day and like a billion connections an hour, like with some of our customers do, it's no longer possible to look at like, you know, connections, it's no longer possible to look at every process. You've got to have to figure out how to deal with that problem by doing, you know, lot of data processing and clustering and that's what we do well, but at some point, scalability basically comes up when you end up having to, on any of the dimensions, having to deal with the problem where I can't, you know, as a human, I can't look at everything. So you have to kind of at that point start investing in anomaly detection figuring needle in the haystack problems so we can focus on them versus like, you know, one VM something happened. Yeah. All right, Vikram, really appreciate the updates. We know we're going to see Lacework at many of the cloud shows, appreciate all the updates, everything in the Kubernetes environment. Thanks for joining us. Yeah, thanks a lot, good to be here. For John Troyer, I'm Stu Miniman. Back with more coverage here in just a little bit. Thanks as always for watching theCUBE.