Cloud security is, or at least should be, a top agenda item for board members. And as more enterprises are building and running applications with a cloud-native approach, security teams and developers need a shared language to tackle data breaches before small problems become big issues that impact customers.

So even though cloud-native applications are running faster and the architecture may prove more reliable, tech companies such as Lacework Inc. are making sure that security isn’t compromised with much-needed threat detection that leverages the teamwork that’s integral between developer operations and security teams.

“If you look at the cloud ecosystem and Kubernetes now with containers, it’s very clear that it requires a new way to look at security,” said Vikram Kapoor, co-founder and chief technology officer of Lacework. “All the traditional security tools for the data center were really based on network, and then as we moved to the cloud, it’s very hard to take a hardware box to the cloud — even with the virtual boxes, it’s really not that clean and a good architecture.”

Kapoor went on to explain: “What we found was that 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 to cover compliance and governance and breach protection automatically.” 

Kapoor spoke with Stu Miniman (@stu), host of theCUBE, SiliconANGLE Media’s mobile livestreaming studio, and guest host John Troyer (@jtroyer), chief reckoner at TechReckoning, during the KubeCon + CloudNativeCon event in San Diego, California. They discussed Kubernetes, cloud security, and why it’s essential for security teams and developers to work together. (*Disclosure below.)

[Editor’s note: The following answers have been condensed for clarity.]

Stu: 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 take it into Kubernetes, and that means I can take my database across all the environments and I get to keep them there.” Does that line up with how we should think about cloud security, or is it a little bit different than that?

Kapoor: It’s a little bit different than that. If you do all that, then what cloud-native typically would also bring with itself would be things like your VMs and containers are not long-running, they’re short-running. In the old world, I’ve been developing for 20 years, I knew the IP address 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?” I don’t know. 

There’s a lot of elasticity, dynamic stuff that comes along with it. Network clearance 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. 

Stu: I remember a couple of years ago, there was a security issue inside of Kubernetes; the community freaked out a little bit, but it ended up moving past that. What are those security risks inside Kubernetes, and where does Lacework fit into that discussion?

Kapoor: I think it’s really around thinking about governance not as an isolated platform but actually part of the tech stack in the ecosystem and looking holistically across it. Fundamentally, some of the security concerns haven’t changed. You need to make sure you don’t leave those open, right? So, if I have a door open on my API level, 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 you have to monitor that also. It has its own pods and 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 worked with the tech security. But they obviously need to work together to make sure that before they deploy it, it’s architected the right way, it has the correct VPCs and the pod policies and the pod architecture. At the same time, at run time, make sure you’re monitoring it so that if something happens you know about it early versus six months later when the data is leaving the data center. It’s too late at that point.

Troyer: 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 Lacework. Can you talk a little bit about the enterprise situation? I’m guessing, versus a start-up, there’s a few other requirements that are coming to the table.

Kapoor: Fundamentally, DevOps and security really have to be on the same page, because at the end of the day it’s a very API-centric world. Everything I do on AWS or GCP Azure or Kubernetes is through an API, so it’s a developer-centered world. If I have to set up a VPC, I have to work with a DevOps center. If I have to set up security groups, I have to work with DevOps to set it. If they’re not on the same page, you end up having problems. 

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 applications, they can look at the behavior, and they can understand what the architecture is. They can have a shared vocabulary and a language. 

I think we see that and I feel long term it’s really a collaboration where security brings to the table a lot of the know-how in how to secure something. At the same time an actual implementation of it probably belongs in DevOps, where if you want to enforce something, you probably have to work with Kubernetes and Kubernetes API structure to enforce it, so it goes both ways.

Watch the complete video interview below, and be sure to check out more of SiliconANGLE’s and theCUBE’s coverage of the KubeCon + CloudNativeCon event. (* Disclosure: Lacework Inc. sponsored this segment of theCUBE. Neither Lacework nor other sponsors have editorial control over content on theCUBE or SiliconANGLE.) 

Photo: SiliconANGLE