More than ever, application security is a top priority. Beyond secure coding practices, a holistic app security strategy addresses the full application and infrastructure stack. This includes containers, microservices, orchestration, infrastructure software and the cloud. Bolting on the next security tool may not be the answer.
Kamal Shah, StackRox CEO, joins us on this DevOps Chat, diving into the need for a systemic security approach across the life cycle of cloud-native, even “Kubenative,” applications. We explore how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. It’s a fascinating conversation that will open up new paths to secure Kubernetes and cloud-native applications.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Mitch Ashley: Hi, this is Mitch Ashley from devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Kamal Shah, who’s CEO of StackRox. Our topic today is security in a cloud-native world. Kamal, welcome to DevOps Chat.
Kamal Shah: It’s great to be here, Mitch. Thank you for having me.
Ashley: Well, I really appreciate you taking time out of your schedule. I know you’re very busy. Happy to have you on. Would you start by introducing yourself? Tell us a little bit about you and what you do. Of course as CEO we can imagine, but also a little bit about StackRox.
Shah: Absolutely. So again, I’m Kamal Shah. I’m the CEO of StackRox, and StackRox is a leading provider of security and compliance solutions for your cloud-native infrastructure. So as you’re embarking on your journey towards microservices, containers and Kubernetes, we help you address your security and compliance requirements across the entire application life cycle from build to deploy to runtime.
Ashley: It’s about secure software, especially in a cloud-native containerized world. That’s for sure. Well, tell us a little bit about how you approach this problem? You know, how do you think about security in a kind of contemporary app development world where you’re doing cloud-native applications? Kub-native, I know is a way that we like to talk about it. How do you approach this from a StackRox standpoint?
Shah: Absolutely. And so the big trend that we saw when we started the company was that customers were, you know, shifting their monolithic applications built on traditional infrastructure to microservices and containers and as a result security also had to evolve to meet and secure this cloud-native infrastructure. And we saw an opportunity to build a new set of solutions that are purpose built for this cloud-native infrastructure, because when you really think about it there’s fundamental differences between traditional application and traditional security and cloud-native applications and cloud-native security, right? I mean you’re deploying containers; security then has to make sure that it understands the ephemeral and immutable nature of containers and security has to shift left and provide controls and guardrails for the build and deploy side of the application life cycle, not just at run time.
And equally important, security now has to seamlessly integrate with DevOps processes, automation and workflow, because if you don’t then the DevOps organ is gonna reject—or sorry, the DevOps body is gonna reject the security organ.
Ashley: [Laughs] I’m glad you talked about it in both ways because Kubernetes, containers, that obviously changed the architecture of software and how we’re doing that in the cloud. You know, it isn’t just about locking down servers anymore. It’s really app security level, but at the same time we’re creating software differently. Can you say some more about what maybe some of the unique challenges are that you’ve had to address for both cloud-native world and also shift left within DevOps?
Shah: Yeah, absolutely. I mean the one big trend, people talk a lot about microservices and containers, but the other big thing that I would like to call out is that Kubernetes has emerged as the de facto standard for orchestrators, right? We did a survey late last year and again six months later and what we found is the adoption of Kubernetes as the orchestrator has grown from 57 percent of organizations using it to now, you know, over 86 percent of organizations using Kubernetes, right?
Ashley: Wow.
Shah: And for the right reasons, because it is really, really hard to scale, manage, and deploy containers in large environments, and Kubernetes was purpose built to help you do that. It was an opensource system developed by Google, and Google today uses Kubernetes or a version of Kubernetes, the internal version, to manage over 4 billion deployments at 4 billion containers at scale. So the first thing here is that you have to appreciate the importance of Kubernetes and you have to make sure that security is focused on not just the container but also at the orchestrator and specifically Kubernetes, right?
Ashley: Sure.
Shah: And that itself brings a whole new set of challenges because Kubernetes is a large system with significant operational complexity, right? And they just went through a security audit and the assessment team found that the configuration and deployment of Kubernetes is nontrivial, and I can get into the details as to what those challenges are, but the starting point is to make sure that you’re not just focusing on security at the container layer but also focusing at the Kubernetes layer.
Ashley: Well, isn’t that the truth. We find so often even outside of the container world it’s oftentimes configuration issues, not just the software itself. And as you mentioned, Kubernetes, well as great as it is, it is very complex to set up and operate. It’s not a simple task. Maybe it is as a developer to get an environment running but not in a multi-cluster distributed environment in the cloud, et cetera, high bred, all that kind of thing.
Shah: They highlighted, you know, the three reasons why it is nontrivial. The first reason was that there are certain missing operational controls, right? So you obviously have to make sure that you understand what those are and put guardrails in place for those controls. The second is that there are a lot of components that have ability to put controls in place but the default settings are confusing, and the big takeaway for me is that we need to distinguish between security controls being available by default and that doesn’t mean that they are configured securely by default, right? So the misconfiguration is therefore the number one concern that users have and it was expressed by two-thirds of the audience in the StackRox State of Container Security Report that two-thirds of the respondents were concerned about misconfigurations.
Ashley: I believe you even have that report or some information about that on your website. I remember downloading some of that. It has some great information in it. Talk to us about then how do you approach that from a StackRox product standpoint? What parts of those issues does StackRox come in and really help you solve?
Shah: Yeah. So, you know, what we have taken is really a holistic approach to container and Kubernetes security and we have focused on making sure that our approach is both container-native and Kubernetes-native. So what does that mean? It means two distinct things. First is making sure that we capture all the rich configuration data that is in Kubernetes and use that to address and improve the efficiency of all the use cases that we address in the product. So let’s take vulnerability management as a very simple use case, right? You can go scan images and say here are a list of all the images with a vulnerability score of seven or higher.
Now imagine you have hundreds of images with vulnerabilities and you give them to developers. What are they gonna do? And I say, well, they’re gonna throw their hands up in the air and say, “Well, I can’t get to all of them,” and that’s where we had the Equifax problem. But by deeply integrating with Kubernetes and being Kubernetes-native, what StackRox does is takes the additional step of saying, “Hey, you know, it’s great that we have these images with vulnerabilities, that’s a good, important first step, but let’s take the second and third and fourth step to understand are those images even deployed anywhere in your production environment?”
Ashley: Exactly.
Shah: Right? And if they’re employed in production environment, what data is it accessing, what secret is it accessing, what’s the network configuration, is it publicly accessible, what behavior are we seeing at runtime? And by taking all this rich context we can t hen give you a prioritized list of risks in your environment so you can focus on the most important risks first as opposed to getting a laundry list of issues. So that’s an important—you know, that’s how Kubernetes-native solutions can help you prioritize risk and that’s precisely what we do at StackRox.
Ashley: I was just going to say, I think this is an extremely valuable aspect of your product because so many security teams—and I’ve talked to even, you know, major online tech companies that say, “I don’t need more information; I need problems solved, right? Tell me what are the biggest, most important things to go after,” and I think that’s a huge part of what StackRox does.
Shah: Exactly. And, you know, alert fatigue, as I’m sure you’ve heard, is a very common problem in the security industry.
Ashley: That’s the nice way to say it. [Laughs]
Shah: Yeah. And by leverage the context, the rich context available in Kubernetes, you can actually make that information more actionable for your development teams and your security teams. So that’s one example. The other example of what it means to be Kubernetes-native is really to leverage the built-in controls available in Kubernetes for policy enforcement, right? And so let’s take network segmentation as another use case where you want to segment your networks between—inside—so that not every container can talk to every container, and there are two approaches. You know, Kubernetes has something called Network Policies and you can leverage those, and it’s much more scalable and robust and it seamlessly deploys within your infrastructure, right?
The other approach would be to go deploy a proprietary firewall, which is fraught with scale challenges and creates issues if it fails, right? And so a customer again says, “Hey look, when I’m talking about being Kubernetes-native I want to leverage Kubernetes for what it’s designed to do, leverage the native capabilities, because it’s much more scalable and robust, and I want to make sure that my controls are all in Kubernetes, have a central place for policy enforcement as opposed to multiple proprietary tools doing policy enforcement,” which is not the approach and not what Kubernetes recommends and that’s precisely why they have those built-in controls. And so that’s again another example of what—you know, the advantages of being Kubernetes-native and it allows for native enforcement of your policies.
Ashley: Well, I think that’s another place where, you know, the DevOps intersects with other parts of the organization, DevSecOps, et cetera. You know, a security team might be used to locking down a server or at a massive application level, and as you’ve mentioned sort of outside of the Kubernetes environment locking something down at the firewall, that doesn’t deal with really what’s happening amongst all the clusters, all the containers, microservices. So you’ve really highlighted an important aspect of security, that once security teams get engaged and find out what’s possible now they can, you know, do that through StackRox. That’s gotta be a huge advantage.
Shah: Yeah, and precisely the reason why we took this approach, because when we go talk to customers what we find is that there are security teams that care about the controls that we are talking about here and then there are platform and infrastructure teams that are responsible for the operationalization of these tools, right? They are responsible for SLAs. The SREs are the ones that have to operate these container and Kubernetes-native security solutions and, you know, they just prefer solutions that are more native to the infrastructure versus deploying proprietary third party tools. And so having a Kub-native approach also helps align security and DevOps teams, and what we are seeing now is as a result that this emergence of DevSecOps, which is all about bringing the two together and really being responsible for the security of your application and your cloud-native infrastructure.
Ashley: I’m curious. Who is it usually that’s reaching out to you or showing interest in StackRox? Is it the developers, DevOps folks, is it security folks kind of figuring out how to talk to the dev teams? What do you see happening in the market?
Shah: Yeah, and a great question. We typically see security teams or security architects or application architects reach out because they know they have to address it, and so that’s where the initial conversation starts. What we find is that when they involve the DevOps teams, because they have to get involved to do a proof of concept or even to deploy an operationalized solution, the DevOps teams actually much prefer a container and Kubernetes-native approach as opposed to a proprietary third party security tool because they often refer to proprietary tools as a root kit that they do not want to install in their infrastructure, right? And so it is—you have to speak to both audiences.
You have to make sure that you cover all the use cases that security teams care about and you also have to make sure that from a day-to-day operationalization of the product it aligns with your DevOps teams, their processes, their workflows.
Ashley: I have to believe that’s gotta be a big plus to the security team. It’s not another security tool that they bolt on to the network. It’s something that’s built into Kubernetes and managed through Kubernetes and StackRox. It’s also native to the application infrastructure versus something they have to integrate in or yet another tool to watch. It just seems to be much simpler, although it’s a complex topic, but simpler thing to implement as well as manage.
Shah: Absolutely. I mean you said it spot on. This is security that’s built in versus security that’s bolted on, and if you think about where the security industry is headed it’s all about security as code, right? Where you built it into your applications. People talk about infrastructure as code, which is what we’ve been doing for the past five years, and now we are moving to this security as code where it presents us with a unique opportunity to address security from the very beginning and forever change the security equation in our favor.
Ashley: I’m curious. When we talk about shift left for security, I think bundled inside that, really what’s also shifting left, is auditing and compliance. Are there things about a Kub-native environment that help us with that as well, the auditing and compliance aspects of security?
Shah: Yeah. Absolutely. When we think about compliance and, you know, shift left you want to make sure that your Center for Internet Security benchmarks cover both your containers as well as your orchestrator in Kubernetes. If you’re doing any kind of PCI or HIPAA or NIST 800-190 compliance controls you want to make sure that you extend them not just to your containers but also to your orchestrator in Kubernetes specifically. The whole shift left movement is that if I can catch an issue early on and prevent it from being deployed in my environment that is 100 times more effective than deploying it in my environment and then catching it when something goes wrong, right? So the sooner—it’s more preventative as opposed to, hey, we’re gonna detect it—let anything run in the environment; we’ll detect everything bad that happens.
And, you know, and as we know that’s not effective. You have to have preventative solutions, you have to have guardrails in place that harden your environment so you have fewer chances of things going wrong. And that said, you also need capabilities at runtime, so despite your best efforts, when things do go wrong, you can still catch them and prevent any damage from happening.
Ashley: Well, that’s the whole observability tracing into microservice, et cetera, understanding what’s happening in the environment. You have to know what the environment is in the first place as well as tie it back to that data.
Shah: Exactly. And I think what we’re going to see is logs and metrics and tracing forming observability as you point out; and similarly, you know, security is just the other side of the coin, right? So observability and security go hand in hand. What we are doing is leveraging all of that rich information that is available at the node level, at the cluster level, and leveraging that to protect your applications across the entire lifecycle.
Ashley: Excellent. Well, we’re coming up on the end of our time here. One last thought. Is there a certain best practice or something that you’ve observed as you work with customers when they begin engaging with StackRox and see your technology and what it can do for them? What is the thing that they walk away saying, “Wow, this has really helped me and I’ve solved the following problem or knowing the following has saved me a lot from avoiding some problems”?
Shah: Yeah. So there are a lot of, you know, great resources available on our website at www.StackRox.com, and we talk a lot on misconfigurations and we’ve highlighted some best practices. For example, making sure that you use a read-only root file system, right? Because that’s a very powerful mitigation against attempts to gain foothold in your infrastructure and the adversary’s job becomes that much more difficult. Or minimize the image contents, because a lot of file systems often contain bash or package managers which further enable an attacker to do bad things, and so remove all nonessential binaries or pay attention to your Kubernetes RBAC configuration.
Why? Because Kubernetes API is a critical attack surface. It controls what happens in your cluster and it controls what security configurations are in your cluster, and so if you minimize who has access to that Kubernetes API it prevents—it again hardens your environment, and also upgraded to the latest version because Kubernetes, the community, is constantly adding more and more security controls, they’re constantly addressing vulnerabilities that are discovered, and so running on the latest version of Kubernetes is also an important step that you can take to secure your Kubernetes environment. So there are lots of other, you know, best practices that I would call low-hanging fruit that we’ve called out on some blogs that we’ve written about, and that’s irrespective of whether or not you’re using StackRox, right? These are just some good best practices as you embark on your journey to containers and Kubernetes.
Ashley: You do have an excellent blog and I would certainly recommend that to our listeners. Well, it’s been great talking with you. Kamal, thanks for being on the podcast.
Shah: Mitch, thank you so much for having me.
Ashley: It’s definitely been my pleasure. So I’d like to thank Kamal Shah, CEO of StackRox, for joining us today. You, of course, have listened to another DevOps Chat podcast and I’d like to, of course, thank our listeners for joining us today as well. This is Mitch Ashley with devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.
— Mitchell Ashley
