 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2021 virtual. Brought to you by Red Hat, the CloudNative Computing Foundation and ecosystem partners. All right, welcome back to theCUBE's coverage of KubeCon and CloudNativeCon 2021 virtual. I'm John Furrier, host of theCUBE. He was a great guest. I'm excited to talk to his company that he was part of, founding CTO, was bought by Red Hat, Ali Ghoshan, senior director of global software engineering at Red Hat, formerly the CTO of StackRocks. Ali, thanks for coming on, appreciate it. Thanks for joining us. Yeah, thanks for having me. Excited to be here. So big acquisition in January. We covered it on SiliconANGLE. You guys, security company, venture backed, Amplify, Sequoia and on and on. Big part of Red Hat's story in their security as developers want to shift left, as they say, and as more and more modern applications are being developed. So congratulations. Real quick, just quick highlight of what you guys do as a company and inside Red Hat. Sure. So the company's premise was built around how do you bring security to the entire application lifecycle? So StackRocks focuses on sort of three big areas that we talk about. One is how do you secure the supply chain? The second part of it is how do you secure infrastructure and posture management? And then the third part is now how do you protect the workload that run on top of that infrastructure? So this is the part that aligned really well with Red Hat, which is, Red Hat wanted to take a lot of what we do around infrastructure, posture management, configuration management and developer tools integrated into a lot of the things they do. And obviously the workload protection part was a very seamless part of integrating us into the open shift part because we were built around code native constructs. And obviously Red Hat having, you know, some of the foremost experts around Kubernetes sort of created a really great outfit. Yeah. You guys got a great story. Obviously, cloud native applications are rocking and rolling. You guys were in early serverless merges, Kubernetes and then security in what I call the real time developer workflow. Ones that are building really fast pushing code. Now it's called day two operations. So cloud native day two operations kind of encapsulates this new environment. You guys were right in the sweet spot of that. So this became quite the big deal. Red Hat saw an opportunity to bring you in. What was the motivation when you guys did the deal? Was it like, wow, this is a good fit? How did you react? What was the vibe at Stack Rocks when this was all going down? Yeah. So I think there's really three areas you look for anytime a company comes up and sort of starts knocking on your door. One is really, is the team going to be the right fit? You know, is the culture going to be the right environment for the people for us? That was the big part of what we were taking into consideration. We found Red Hat's general culture, how they approach people and sort of the overall approach to the community was very much aligned with what we were trying to do. The second part of it was really the product fit. So we had from, you know, very early on started to focus purely on the Kubernetes components and doing everything we could. We called sort of our product approach built in versus bolted on. And this is sort of a philosophy that Red Hat had adopted for a long time. And it's a part of a lot of their developer tools, part of their shift left story as well as part of OpenShift. And then the third part of it was really the larger strategy of how do you go to market? So we were hitting that point where we were in triple digit customers and we were thinking about scalability and how do we scale the company? And that was the part that also fit really well, which was obviously Red Hat more and more hearing from their customers about the importance and the criticality of security. So that last part happened to be one part we ended up spending a lot of time on and ended up being sort of three out of three matches that made this acquisition happen. Well, congratulations, always great to see startups in the right position, good hustle, great product, great market, you guys did a great job. Congratulations. Now, the big news here at KubeCon, obviously Linux foundation, Open Source, you guys are announcing that you're open sourcing Stackerox. This is huge news, obviously you now work for an Open Source company, I'm sure that was probably a part of it. Take us through the news. This is the top story here for this segment. Take us through Open Source, take us through the news. Yeah, so traditionally, Stackerox was a proprietary tool. We do have open source tooling, but the entire platform in itself was a proprietary tool. This has been a number of discussions that we've had with the Red Hat team from the very beginning. And it sort of aligns around a couple of core philosophies. One is obviously Red Hat at its core being an open source company and being very much plugged into the community and working with users and developers and engineers to be able to sort of get feedback and build better products. But I think the other part of it is that, I think a lot of us from a historic standpoint have viewed security to be a proprietary thing because we've always viewed these sort of magic algorithms or black boxes or some magic under the hood that really moved the needle. And that happens not to be the case anymore. Also because Stackerox's philosophy was really built around Kubernetes and built in, we feel like one of the really great messages around why to open source a security product is to build that trust with the community. Being able to expose here's how the product works, here's how it integrates, here are the actions it takes, here's the ramifications or repercussions of some of the decisions you may make in the product. Those all I feel make for very good stories of how you build connection, trust and communication with the community and actually get feedback on it. And obviously at its core, the company being very much focused on Kubernetes developer tools, service mesh, these are all open source toolings obviously. So for us it was very important to sort of talk to talk and walk to walk. And this is sort of an easy decision at the end of the day for us to take the platform open source. And we're excited about it because I think most people still want a product I supported commercial product. So while it's great to have some of the tip of the spear customers look at it and adopt the open source and be able to drive it themselves, we're still hearing from a lot of the customers that what they do want is really that support and that continuous management maintenance and improvement around the product. So we're actually pretty excited. We think it's only going to increase our velocity and momentum into that community. Well, I have some questions on how it's going to work, but I do want to get your comment because I think this is a pretty big deal. You know, I had a conversation about 10 years ago with Doug Cutting who was the founder of Hadoop. And he was telling me a story about a company he worked for, he did all this coding, they went under and the IP was gone, the software was gone. And it was a story to highlight that proprietary software sometimes could never see the light of day and it doesn't continue. Here, you guys are going to continue the story, continue the code. How does that feel? What's your expectations? How's that going to work? I'm assuming that's what you're going to open it up, which means that anyone can download the code. Is that right? Take us through, how to first of all, do you agree with that? This is going to stay alive and how's it going to work? Yeah, I mean, I think as a founder, one of the most fulfilling things to have is something you build that becomes sustainable and stands the test of time. And I think especially in today's world, open sourcing a tool that is in demand and only in a market that's growing is really a great way to do that, especially if you have a sort of an established user base and a customer base. And then to sort of back that on top of, thousands of customers and users that come with Red Hat in itself, gives us a lot of confidence that that's going to continue and only grow further. So the decision wasn't a difficult one. You know, although transparently, I feel like even if we had pushed back, I think Red Hat was pretty determined about open sourcing again anyway. But it's to say that we actually were in agreement to be able to go down that path. I do think that there's a lot of details to be worked out because obviously there's sort of a lot of the nuances in how you build product and manage it and maintain it. And then how do you introduce community feedback and community collaboration as part of open source projects is another big part of it. I think the part we're really excited about is that it's very important to have really good community engagement, maintenance and response. And for us, even though we actually discussed this particular strategy during Stackbox, one of the hindering aspects of it was really the resources required to be able to manage and maintain such a massive open source project. So having Red Hat behind us and having a lot of this experience was very relevant. I think as a startup to start proprietary and suddenly open it and try to change your entire business model, go to market strategy, commercialization, change the entire culture of the company can sometimes create a lot of headwind. And as a startup, like sort of, I feel like every year just trying not to die until you create that escape velocity. So those were, I think, some of the risk items that Red Hat was able to remove for us and as a result made the decision that much easier. Yeah, and you got the mothership with Red Hat, they've done this before, they've been doing it for generations. You guys, you know, the startup, things are going crazy. It's like whitewater rafting. So everything's happening so fast. And now you got the community behind you because you're going to have the CNC. If you get KubeCon, I mean, it's a pretty great community. The support is amazing. I think the only thing the engineers might want to worry about is go back into the code base and clean things up a bit. That's why I'm trying to see the code. They're like, wait a minute, their names are on it. So it's always a fun time. In all seriousness, no, this is a big, big story on the DevSecOps. And I want to get your thoughts on this because, you know, Kubernetes is still emerging, you know, and DevSecOps, DevOps is awesome. We've been covering that for all of the life of the queue for the 11 years now and the greatness of DevOps. But now DevSecOps is critical and Kubernetes native security is what people are looking at. When you look at that trend only continuing, what's your focus? What do you see now that you're in Red Hat as the CTO, former CTO of StackRocks and now part of Red Hat, it's going to get bigger and stronger Kubernetes native and shifting left and or DevSecOps. What's your focus? Yeah. So I would say our focus is really around two big buckets. One is Kubernetes native sort of a different way to think about it as we think about our roadmap planning and go-to-market strategy is it's mutually exclusive with being infrastructure native. That's how we think about it. As a startup, we really have to focus on an area and Kubernetes was a great place for us to focus on because it was becoming the dominant orchestration engine. Now that we have the resources and the power of Red Hat behind us, the way we're thinking about this is infrastructure native. So thinking about cloud native infrastructure where you're using composable, reusable constructs and objects, how do you build potential offerings or features or security components that don't rely on third-party tools or components anymore? How do you leverage the existing infrastructure itself to be able to conduct some of these traditional use cases? And one example we use for this particular scenario is networking. Networking the way firewalling and segmentation was typically done was people would tweak IP tables or they would install, for example, a proxy or a container that would terminate NTLS or become inline and it would create all sorts of sort of operational and risk overhead for users and for customers. And one of the things we're really proud of as sort of the company that pioneered this notion of cloud native security is if you just leverage network policies in Kubernetes you don't have to be in line. You don't have to have additional privileges. You don't have to create additional risk or operational overhead for users. So we're taking those sort of core philosophies and extending them the same way we did to Kubernetes all the way through service mesh. So we're doing the same sorts of things through Istio being able to do a lot of the things people that are traditionally doing through, for example, proxies through layer six and seven, we want to do through Istio. And then the same way, for example, we introduced a product called KubeLinter which was an open source tool which would basically look at YAML on Helm charts and give you best practices responses. And it's something you point, for example, to your Git repository. We want to take those sort of principles enabling developers giving them feedback allowing them not to break their existing workflows and leveraging components in existing infrastructure to be able to sort of push security into cloud native and really the two pillars we look at are ensuring we can get users and customers up and running as quickly as possible and reduce as much as possible operational overhead for them over time. So we feel these two are really at the core of open sourcing and building into the infrastructure which has sort of given us momentum over the last six years and we feel pretty confident with Red Hat's help we can even expand that further. Yeah, I mean, you bring up a good point and certainly as you get more scale with Red Hat and on the customer base, you know, not only in dealing with the threat detection around containers and cloud native applications, you got to kind of build into the life cycle and you got to figure out, okay, it's not just Kubernetes anymore, it's something else. And you got advanced cluster security with Red Hat, they got OpenShift cloud platform, you're going to have managed services. So this means that you're going to have scale, right? So how do you view that? Because now you're going to have, you guys at the center of the advanced cluster security paradigm for Red Hat, that's a big deal for them. And they got a lot of R&D and a lot of, I wouldn't say R&D, emerging technologies developing around that. We covered that in depth. So when you start to get into advanced cluster, it's just, it's compliance too. It's not just threat detection, you got insights, telemetry, data acquisition. So you have to kind of be part of that now. How do you guys feel about that? Are you up for the task? What's your story? Yeah, I hope so. It's early days, but we feel pretty confident about it. We have a very good team. So as part of the advanced cluster security, we work also very closely with the advanced cluster management team in Red Hat because it's not just about security, it's about how do you operationalize it, how do you manage it, maintain it into your point, sort of run it long-term at scale. The compliance part of it is a very important part. I still feel like that's in its infancy and these are a lot of conversations we're having internally at Red Hat, which is, we all feel that compliance is going to sort of more from, the standard benchmarks you have from CIS or particular compliance requirements, like the power of PCI or NIST, into how do you create more flexible and composable policies through a unified language that allows you to be able to create more custom or more useful things specific to your business. So this is actually an area where we're doing a lot of collaboration with the advanced cluster management team, which is that how do you sort of bring to light a really easy way for customers to be able to describe and sort of abstract policies and then at the same time be able to actually implement and enforce them. So we think that's really the next key point of what we have to accomplish to be able to sort of not only gain scale, but to be able to take this notion of not only detection and response, but be able to actually build in what we call declarative security into your infrastructure. And what that means is to be able to really dictate how you want your applications, your services, your infrastructure to be configured and run and then anything that is sort of conflicting with that is auto responded to. And I think that's really the larger vision that with Red Hat would find it accomplished. And that's a nice posture to have. You build it in, get it built in, you have the declarative models, then you kind of go from there and then let the automation kick in. You got insights coming in from Red Hat. So all these things are kind of evolving. It's still early days and I think it's a nice move by Red Hat. So congratulations. Final question for you is as you prepare to go the next generation, KubeCon is also seeing a lot more end user participation. People, you know, cloud native is going mainstream. When I say mainstream, I'm seeing beyond the hyperscales and the early adopters, Kubernetes and other infrastructure control planes are coming in. You start to see the platforms emerge. Nobody wants another security tool, right? They want platforms that enable applications and or tools. As it gets more complicated, what's going to be the easy button and security cloud native? What's the approach? What's your vision on what's next? Yeah, so, you know, I don't know if there is an easy button in security. And I think part of it is that there's just such a fragmentation in use cases and sort of designs and infrastructure that that doesn't exist, especially if you're dealing with such a complex stack. And not only just a complex stack, but potentially use cases that not only span runtime, but they deal with your deployment and your development lifecycle. So the way we think about it is more sort of this notion that has been around for a long time, which is the shared responsibility model. Security is not security's job anymore, especially because security teams probably cannot really keep up with the learning curve. Like they have to understand containers. Then they have to understand Kubernetes and Istio and Envoy and cloud platforms and APIs. And, you know, there's just too much happening. So the way we think about it is if you deal with security in a declarative fashion, and if you can state things in a way where how infrastructure is ran is properly configured. So it's more about safety than security. Then what you can do is push a lot of these best practices back as part of your Git process. Involve developers, engineers, the right product security team that are responsible for day-to-day managing and maintaining these. And the example we think about is like CVEs. There are plenty of, for example, vulnerability tools, but the CVEs are still an unsolved problem because, you know, where are they? What is the impact? Are they actually running? Are they being exploited in the wild? All these things have different ramifications as you span it across the lifecycle. So for us, it's about understanding context, understanding assets, ensuring how the infrastructure has to handle that asset and then ensuring that the route for that response is sent to the right team so they can address it properly. And I think that's really our larger vision is how can you automate this entire lifecycle? So the information is routed to the right teams, the right teams are appending it to the application. And in the future, our goal is not to just pardon the workload or the compute environment, but use this information to actually pardon application themselves so that creates that additional agility and scalability. Yeah, it's in the lifecycle of that build-in, right? In the beginning, more productivity, more security, and then letting everything take over on the automation side. All the congratulations on the acquisition to end with the Red Hat buyout. That was great for them and for you guys. Take a minute, quickly, this final, final question for the folks watching here. The big news is your open sourcing Stack Rocks. So that's a big news here at KubeCon. Obviously, what can people do to get involved? Would you share a quick commercial for what people can do to get involved? What are you guys looking for? Take a pledge to the community. Yeah, I mean, what we're looking for is more involvement and direct feedback from our community, from our users, from our customers. So there's a number, obviously, the Stack Rocks platform itself being open sourced. We have other open-source tools like the KubeLinter. What we're looking for is feedback from users as to what are the pain points that they're trying to solve for? And then give us feedback as to how we're not addressing those or how can we better design our systems? I mean, this is the sort of feedback we're looking for and naturally, with more resources, we can be a lot faster in response. So send us feedback, good or bad. We would love to hear from our users and our customers and get a better sense of what they're looking for. Innovation out in the open, love it. Got to love open source going next gen. I like all Sean senior director of global software engineering a new title at Red Hat, former CTO founder of Stack Rocks which spread out acquired in January, 2021. Thanks for coming on, congratulations. Thanks for having me. Okay, so it keeps coverage of KubeCon, CloudNativeCon 2021. I'm John Furrier, your host. Thanks for watching.