 Good morning, good afternoon, good evening, and welcome to a special edition of In the Clouds. I am Chris Short, host of Red Hat Live Streaming, and I am joined by the one and only Wei Ling Dang, Senior Director of Hiver Platforms Product and Marketing here at Red Hat. He's also the former Co-Founder and Chief Strategy Officer at StackRocks, who was acquired by Red Hat not too long ago. How are you today, Wei? I'm doing well, Chris. Thanks. And thanks for having me here. It's great to be on. Hey, it's great to have you on. Thanks for saying yes. So, I've been looking forward to this one, believe it or not, because I've been a StackRocks fan for a while now. Back in KubeCon, San Diego, the StackRocks folks asked if I could just do a high-level security talk about the CNCF landscape, basically, and all the tools that are in it. And I really had an appreciation for StackRocks because you didn't necessarily make yourself so hard to replicate. You stayed Kubernetes native. Somebody could have done the exact same thing you did potentially in a different way and still use those native components, or they could have gone a more proprietary route, which I think is part of the reason why we were like, ooh, we should acquire StackRocks. Can you tell me, A, a little bit about yourself? And we'll skip the icebreaker question because you went meta-universe on me for that. So let's just dive right in. Introduce yourself and talk to me about StackRocks becoming part of Red Hat. Sure. So I was a co-founder at StackRocks, and today I head up what we've rebranded the product as, which is Red Hat Advanced Cluster Security for Kubernetes or ACS for short. And as you mentioned, one of the really key approaches that we talk around thinking about how security should be handled in these environments is to go with what we call Kubernetes native. And what we think of as Kube native is about integrating with the existing security capabilities and controls that exist in Kubernetes, allowing users to utilize the same abstractions and constructs and primitives that they're already familiar with, but also extending those capabilities to address use cases across the entire life cycle. So vulnerability management, configuration management, compliance, threat detection, all those things that give you sort of an end-to-end security platform from build to runtime. And for me, just kind of how I got into the space for a bit is I've been in and around infrastructure and infrastructure security for the last decade or so. So I worked at large companies focused on cloud infrastructure and virtualization and then actually joined a company called Corals as head of product. And that company was also acquired by Red Hat. So in some sense, all roads lead to Red Hat. But I think if you went back like five years in the ecosystem, five, six years and Kubernetes was still a little bit more nascent, there was a lot of interest and demand for starting to run cloud-native technologies in production and for mission-critical use cases, as you know. But there were significant gaps in security capabilities. And so companies like Red Hat and other contributors started to think about how they could insert and build out things like role-based access control and other related capabilities that would instill more confidence in using CUBE and related software in environments where security was a significant consideration. Yeah, and it's one of those things like I used to work in very restricted environments. And one of those things, if you didn't stick it, you weren't putting it on the network. So there was this process of all offline until it went onto a network that was disconnected from the internet. So it's like, well, wait a minute. Why do we have to worry about the internal stuff? But yes, you can't let, there's all kinds of security breaches that have happened because of either bad user education or bad controls. And stack rocks and ACS bring a lot to the table in that regard, I feel like. For sure. To be fair, it's security is complex. And if you look at so many layers of the stacks, so many parts of the life cycle, something can easily go missed or go wrong or unexpectedly. And I know you want to talk about this, but this is where I think getting more people into the mix, more eyes on a particular topic can really help. But for us, I think the whole decision to go around KubeNative was to try to align with how the cloud native community was thinking about it, how the ecosystem around CNCF and so on, how they wanted to approach being open in terms of solving key security problems that have existed. So for us, KubeNative is also about aligning with the overall direction of how the extended KubeNative community and cloud native community is thinking about security. Right. And you mentioned security being hard. I mean, nowadays it's harder than ever it feels like. If you have watched the headlines from 2021, it's either been coronavirus or ransomware. Right. So it's one or the other. Right. And we've got an executive order to talk about all manners of securities and safeties that are going to be put in place or should be put in place. But now we have NIST standards. We have a hardening guide from the NSA. We have CIS benchmark. We have guidance to make the entire pipeline solid. Where does ACS fit in the pipeline? And where do you think people benefit the most from its capabilities? Sure. And to your point about cybersecurity being top of mind, I mean, just reading this morning about how the presence being with CEOs of a bunch of tech companies and trying to figure out sort of these pressing issues around cybersecurity that make a more open dialogue, I think, across the industry. But I think when it comes to industry standards, I think one of the great things is that people have started to coalesce around this sort of set of best practices when it comes to securing containers and Kubernetes and things like that. And you mentioned some of the organizations that have been publishing guidelines. And I do think if you kind of look at or read through those in detail, and I mean, they can make your eyes water a bit. Oh, yeah. They get really detailed. But I think if you kind of take a step back, I mean, there is a lot of overlap between them. And I think what that signals is that there is somewhat broad recognition or fairly broad recognition that there's a set of common methodologies or controls or things people should really think about getting started with. And now, look, there's a lot, like if you look at, say, the CIS Ben Torrance, I mean, there's like hundreds of checks or something like that, right? Oh, yeah. So I think how ACS fits in is in two ways, which is, and I think it fits in with how someone might approach tackling these things. One is that you can't try to get hundreds of things out of the box yourself. Right. No, not possible. I think one is think about where you start. And I think the starting point for nearly every organization or end user is typically with build. As you're building images, container images, how do you think about securing them? How do you prevent vulnerable software from entering your environment? Those are like, just like the low hanging fruit, I think that exists for people to start with. And then how ACS enables that is, we give you a more turnkey experience in terms of automating those checks and providing those by default out of the box. Our whole philosophy is like, we want to make these environments secure by default. And that's not to say that it takes away your choice of how you might want to customize or meet specific needs of your applications or your environments or your organization, no policies. But we want to give you a reference point to start with. Otherwise, like I said, you start with these manuals effectively and you're just like, how do I actually know about this? It's impractical in most cases. Right. Yeah. And so this brings us to the intersection of automation, which to me means DevOps and security, which means DevSecOps and containers and kind of like the two intercept pretty hard and fast nowadays. But where can people find actionable places to start injecting in their pipeline? Not just at container build time, but making that repeatable is also very important too. Right. Sure. And because for your perspective, I mean, I think for me, something to think about this in terms like there's the abstract and then there's a very practical. I think conceptually, there's so much in terms of how containers and DevSecOps can complement each other in the sense that okay, it's like developers and DevOps teams are the ones who are really driving the usage of containerization. And with DevSecOps, you want to shift left and have those individuals start to think about security early in the life cycle anyways. And then there's like the properties of containers. It's like they're meant to be declarative. You can kind of specify and scope down what a given container is supposed to do. And that also helps security. And it makes it easier for people who are more targeted in terms of how they're operating for a given application to actually understand what security controls need to be assigned to or apply to a particular application. I think practically, where it makes sense to start with injecting security controls is as you're building, I would even say even before you're building images. I talk to people and I'm like, hey, think about what registry you're going to allow image pools from. Make sure it's like a trusted registry, like either your own or like from a reputable vendor. I mean, look, even public image repositories from large vendors still have backdoor images. You hear about it kind of on and off throughout the year. It's like, oh, well, if that little Node.js package had something, then that means this container everywhere had something. So yeah, like it's scary out there, right? Well, you know, it's like everyone, everyone's going after, you know, crypto jacking and cryptocurrency mining. Chris, you know, for now, you hear about these like large scale campaigns, you know, that like, you know, Microsoft and others published about. So, but anyways, like, you know, I would say like, where can you start? It's like, you know, when you hook up a registry, when you maybe decide to set up a private registry, it's also you know, for your base images. So even before you build, it's like for your base images, like, is it from a revenue there? Yeah, is it from someone like Red Hat, you know, who's a, you know, trusted reputable vendor? Like, do you have the source code for that base image? Like all those things. So I think, you know, like, there are definitely ways to building good security, you know, approaches in hygiene, like even before you start building, and once you start building, I think, you know, hooking into and taking advantage of automation via, you know, integrating with the CI CD pipeline, you know, often makes sense. And so that could be doing configuration checks, it could be, you know, scanning for vulnerabilities, you know, we, we put out, you know, about a year ago, actually nearly a year ago is like open source tool called kubelinter, which is like, you know, I love that tool. Yeah, it's like, you know, developers are like working with their home charts and YAML files, and, you know, maybe they misconfigured something. So we'll help run a checkup. It happens for sure. Like, you know, you're, you're busy, you're like, you know, you're doing a bunch of things, and, you know, maybe you miss this configuration, like, and so that's how ACS or, you know, stack, you know, sort of, you know, our open source project kubelinter, you know, whatever, whatever else, in terms of how we support across our product portfolio, that's how, you know, we can, you know, help end users kind of avoid some of these problems. Yeah, and just, I'll just read the about real quick for kubelinter. kubelinter is a static analysis tool that checks Kubernetes YAML files and home charts to ensure the applications represented in them adhere to best practices. So there's some best practices baked into this tool, scans the files that you're trying to load into Kubernetes, and you can then, you know, double check that, you know, what you're doing is actually, you know, good, or going to open up some backdoor that you're not aware of. Like, the amount of automation that I think can insert for containers nowadays is vast, right? And kubelinter's just like, just make sure your stuff's good and put it in the repo type thing for me, right? Constantly check those files for new rules, because I mean, you just had a release yesterday of kubelinter. So it's good stuff. So yeah, thank you for mentioning that. You know what, I mean, what are your thoughts, Chris? Like, I mean, you talked to a bunch of folks in the ecosystem and, you know, industry, like, you know, how are they thinking about, like, desecops and containers, like, you know, furthering each other? Just curious to get your perspective. I mean, right now it feels like the hardest thing for a lot of folks to do is to get security out of its mindset of here's your checklist go, right? Like, no, I would like you to be part of the process of getting this code to production, right? Like, there's tooling you use, then please inject it into the pipeline. So, A, getting security, just come talk to you and share tooling has been a problem in my past for sure. And I still think some developers are having that issue and DevOps folks alike are having that issue these days, especially given that a lot of the regulatory stuff is met by policy internally. So a lot of time is being spent writing policies to meet certain new thresholds or certain new guidelines. And it's not necessarily a holistic process now. It's very much siloed still. And that security team used to be pulled in big time. Yeah, but I mean, I don't go, you know, you're saying that, you know, people largely treat it as some sort of checklist. I think it's necessarily surprising. I mean, I think many, many security teams today are overburdened and overwhelmed just in terms of, you know, priorities and sheer number of tools that they have to work with. I mean, yeah. And so even five, six years ago, when container security was starting to become a thing, people were like, oh, but it's down here on my list. But increasingly, it's now bubbling up to one of the top priorities just because they think of the tremendous adoption of Kube and cloud native workloads. Yeah. And if my container file means so much, and if my Kubernetes artifacts mean so much, then they need to be checked for everything just like my code is, right? Like, but we have to put in Kubernetes tooling to do that, it feels like. And some of that tooling can easily be plugged in and some of it is harder to plug in than others, right? Like, we've gone through a couple generations of, you know, digital transformation, as people call it these days. Like, you know, there's still the legacy tooling that folks have to have. There's some newer stuff. And then there's some cloud native stuff. And like, making that pipeline, you know, the same for everybody is hard. So that I mean, having the pipeline first is step one, I feel like, and then plugging every one and everybody into it is step two. If I mean, if I could change a developer's mind about, you know, how important their security team is during this conversation, I think that'd be great. Because if not, right, like, you can't possibly know everything about about anything, right? Like, unless your, you know, subject matter is, you know, very small, you're not going to be able to understand, you know, the underpinnings of Kubernetes and like this FCD vulnerability that just, you know, got zero day by somebody. Like, you're not going to get feedback on that if you don't know about it. So continuous education is a part of it too. But so, like, your tools need to be continually educated as well. I'm kind of curious, you know, with Q blunter and with, you know, advanced container security for Kubernetes, you know, like how how are those rules added? Where do we source things from? And no, there was not an actual at CD zero day. I was just using that as example. I'm sorry. Sorry to scare people. My bad chat. No, there was not an at CD zero day. I was just using that as an example, right? Like, you might find out about it just in time to save your systems, or you might not. Like you've got to have automated security, right? And that's my biggest push, right? Like, plugging the people in, getting things automated and constantly scanning and, you know, remediating things. So, you know, that's why the get ops guide to the galaxy is up next after this call or show. So, yeah, right? Like thinking in that, you know, kind of get ops philosophy. Sorry. I did scare people. Looking at it from like a real time threat detection perspective, where where does ACS sources rules from? How do we, you know, how does ACS do that real time detection? What kinds of things are in place to make that happen? Sure. So, I mean, a couple things on just what you said too. I mean, like, you know, introducing new platform that's as complex as, you know, Kubernetes, like, you know, you're going to, you're going to introduce things like new vulnerabilities and like, you know, the CD thing aside. I mean, like, there have been like, you know, critical or important, you know, new vulnerabilities that have been discovered and disclosed and managed by the community and all of that. But I think, like, part of the answer aside from automation is like delivering some of these capabilities, you know, via the platform. Right. You know, and so take, take OpenShift as an example, because of course, you know, we're Red Hat, but it's just like, and even before ACS. Right. It's like, you could deliver a secure platform and you could surface those things or you could, you know, better protect, you know, organizations from some of these things by baking in the security capabilities into the platform, you know, from, from the beginning. And then, you know, how we think about is like layering ACS, you know, on top. And so, you know, among other areas, you know, one is like, you know, threat protection and sort of asking about that. And, you know, I think for us, you know, I'll talk about, you know, threat detection and policies, but like we've built, you know, our platform to, you know, be extensible and accommodate for, you know, scenarios where new things are going to arise. And so, and in some cases, like, you know, it's going to be specific to, you know, a particular environment. And so where we started is, you know, we wanted to gain sort of like a source of truth, you know, for the data that underpins like threat protection, you know, and I think there's a relative, you know, there's other folks in the ecosystem have thought about it similarly, but I think that it's a relatively new, newer approach, you know, and it's enabled by containers, because, you know, it's less noisy, like you're doing a specific thing, you have a better idea of what, you know, what you're going to do. And so when you look at things like system level data, like, you know, system calls, and, you know, network traffic and things like that, you have a very specific idea of like what a container or microservice or whatever it's supposed to do. You can even correlate that back to like what, you know, the manifest or image, you know, specified. And then you can look at things like, you know, what process executed, like what network request was made, like all of that. And like that all helps like inform, like, better and better, you know, threat detection. And then in terms of like kind of, you know, both detection and policies, I mean, like, you know, this is where I think a community can really, really help. Because, you know, more people can contribute and surface and identify issues that just much harder for, you know, any single organization, you know, to be able to do. And so, you know, this is where like if a new, you know, cool vulnerability is surfaced, then, you know, we'll add that. If there's a new sort of best practice that's, you know, articulated by a SAG or, you know, other, you know, member of the community, we'll look at that and add that. And so, you know, and we look to do that, you know, because, you know, we're in close collaboration with folks, but, you know, at the same time, like, you know, we want to, you know, release that to our, you know, our user basis quickly as possible. But I do think like sort of the openness and community approach has a big, you know, hand in facilitating and enabling, you know, sort of like being more responsive and proactively identifying issues that, you know, I think individual vendors by themselves, you know, would have a harder time doing. Right. Okay. So, you're a, let's see, let me read your title again. Never mind. It's too long. It's too long. So, you're a senior director type and this question just came in via chat and I kind of want your take on it before I respond. Russia is using Kubernetes clusters for brute force attacks. Does CNCF and or Red Hat, I would assume Google have methods of preventing Kubernetes and OpenShift to be used for malicious intent? Well, I think that's probably beyond the scope of, you know, simply what I can answer, but, you know, what likewise, you know, I mean, what I would say is I think Red Hat has been very straightforward in terms of, you know, an entitlement model that, you know, let's, you know, customer, let's end users, utilize its software and part of that is complying with, you know, certain terms and conditions. And so I'm going to defer kind of on, you know, some kind of, you know, definitive answer to that. But to me, it seems like, you know, very plausible or, you know, that it falls outside that scope. But I mean, we definitely have a, you know, very open and straightforward model in terms of how we want, you know, what we allow or how we allow our software to and not to be used. Right. Like at Red Hat, yes, we do have minimal control of licensing, but that doesn't necessarily mean that it's not going to be running, right? Like it's just invalid, right? Yeah. We're not going to get support for it. I mean, we can't put back doors and software folks. We can't. It's not, in my opinion, a wise decision. Now, somebody can differ from me in that opinion. And that's fine. That's your opinion. But no, we do not have a way of having some, you know, kill switch. And, you know, I've read an article yesterday about Samsung having some, something in their TVs, if they're stolen, they can, you know, make them inoperable. And like that to me, right? Like, I'm like, I don't like that, you know, the risk of the risk of that being too, too big brother for you, Chris. A little too big brothery, but the chances of that being now that it's out in the known that there that it's there, the chances of that being exploited are now infinitely higher, right? Because now people are going to go looking for the kill switch and start scanning the internet for Samsung TVs and start poking it and see what they can do with it, right? Like, I would not be surprised if there's a Metasploit module for, you know, Samsung TVs kill switch here in the next couple months. I wouldn't be surprised at all. And I don't like the idea of, you know, kind of vendors being able to like come in and say, nope, you can turn that off now because all kinds of things can go wrong in your infrastructure. There always is a human element to it, right? No matter what. So having that backdoor or having some, you know, process where it's like, oh, I need to log in and do this one thing perfectly every time during your release is destined to be, you know, a point of failure of some sort, either you mess up a flag or you find some other, you know, foul up in your process and your release goes bad. Well, this is where I tend to think, I mean, like, you know, timing and transparency are not inconsistent with each other, you know, I mean, like, think about volums and exploits, so you understand the threat vector. I mean, there's a reason why like, you know, those need to be embargoed sometimes, you know, but, but the intent is, you know, you have, you work with, you know, whoever they're like, you know, relevant stakeholders come up with a solution and then you, you'd be thoughtful about how you disclose it, you know, and at least for, you know, Red Hat and, you know, the broader Coop community with, you know, like their product security committee and things like that. I mean, I think, you know, people have been very thoughtful about how they've approached, you know, new issues at least, you know, in this software platform. But, but yeah, I mean, you know, going back to how things, how things are used, you know, I think there's an aspect of, you know, openness, but I also think, like, you know, Red Hat's been thoughtful about how, you know, we try to historically, you know, made software available for use and which uses and things like that. Yeah. So if, if, here's a good question for you, just came off my head. If you were about to sit down with some new hire at XYZ company and they were on the security team, what would be some of the things you would talk to them about as a, you know, fresh infosec person, right? Like, would it be some of your top talking points there? Well, it's interesting because I think the first thing that stands out is you kind of said like infosec, right? And for me, like, you know, with new hires, everyone, you know, I think largely wants to understand kind of like, what's the vision? Like, what are we trying to, the bigger thing we're trying to do here, you know, aside from, you know, the next feature or like the next sprint or whatever it might be. And I think, you know, the vision is really to change how security is operationalized. Like, you know, the fact that someone may think of it as infosec, you know, I think reflect something because I think in these environments, you can't be thinking of it as some kind of silo and it's not really just infosec. It's, we talked about DevSecOps, but it's really sort of like, organizationally, you need like a culture and you need to build that muscle of like, you know, how you think about security differently. And so that's actually what I would probably spend, you know, most of my time talking about, which is just like, you know, for containers, for CUBE, for cloud data stuff, like, you know, microservices, like, you know, what does security look like? Like, how is it, you know, actually different? And what's the opportunity there to actually build better security? You know, right? You know, and then again, there's like, you know, you can talk about it like conceptually, but I think, you know, we're, you know, we're really making that happen via, you know, an actual platform that, you know, many, many organizations are running today. But I think, you know, new hires that, you know, they kind of get like the bigger picture and they want to, you know, get a sense for, you know, or it's, or it's like, hey, like, what do you think about this project? Like, there's this, you know, latest open source project, like, what are your thoughts? Do you think we'd integrate with it? Like, do you think we could, you know, build on that? Like, how would we fit in? And I mean, I think that's great. Like, you know, the fact that, you know, you could look at the ecosystem today and point to so many different security related projects that address, you know, many, many different problems. I think it's a testament to like, how the community has like, innovated in that area in it, you know, in a space that has historically, as you have pointed out, like typically not been very open. Right. Yeah. And, you know, some people think closed source tools are better because well, they're closed and you can't see the code. Other people think open source tools are better because you can see everything in the open. Why would someone rather work with an open source project in Europe versus something closed source? Well, keeping in mind that ACS is kind of going through that same process, right? Yeah. Yeah. I mean, I think that's allowed us to kind of like look at it from both lenses, you know, I mean, I think that, you know, my personal opinion is that, you know, openness, you know, fosters more confidence, you know, like, and ultimately more, you know, innovation and a better security posture. Like, you have diversity of voices and thoughts and perspectives, you know, you have more eyes on something you can, you know, surface or think through, you know, a security issue, you know, more holistically, more comprehensively. You can think about how you, you know, go forward and build, you know, in a way that you can benefit many, many organizations. And then third is like just practically like, you know, more stable code, like, you know, faster response time, like, just because, you know, you're not reliant on your particular set of individuals. So I think it's this notion that like, by being open, you can actually do more. I've also worked on my share of like close source projects. And I think where that comes in is just like, look, I mean, sometimes, I mean, in most cases to actually like, you know, put out these open source projects, like you need a sustainable business, like you need to be a going concern, right? And so that's where I think, you know, close source, you know, is definitely relevant and can make sense. But I think key question is more like what is closed and what is open, you know, in those scenarios. And it's beyond kind of the subject of like this show, but it's kind of like, yeah, if you're building like, if you're building a business on top of open source, you're kind of like, you know, what needs to be open, what should be open, you know, what doesn't have to be and how do you build a business around it? Yeah, that's kind of the hard part, right? Like building a business around an open source project is indeed difficult. Red Hat has shown success with that, but it's one of the few potentially for sure. I mean, there are some others don't get me wrong, but it, you know, Red Hat forged the way, I guess, I mean, potentially, not trying to sound too bold here, but I mean, you mentioned that transparency does make a difference, right? So being transparent here, what gets you up in the morning? What's something that you enjoy and look forward to in your day here at Red Hat? Or just in the community in general, right? Well, on that, that's easy. I mean, like my kids get me up every morning, like they pull me out, they literally pull me out of bed sometimes. So, you know, and physically, necessarily, but yeah, that works, I guess. No, I mean, you know, I, you know, we didn't talk too much about the acquisition, but I mean, like, you know, I'm thrilled about kind of like what we're doing here, you know, with Red Hat, because because I think like, I think the way forward for, you know, security for all things cloud native is this comprehensive, like, you know, platform that gives, you know, someone in and out of the box, secure experience, like I just, it's just too much, you know, in too complex to figure out, you know, by oneself. And so I think you need, you know, a trusted, you know, platform and vendor like, you know, supporting you, you know, in kind of wherever you are in that journey, you know, to, you know, accomplishing stuff with cloud native software. And to me, I think that that's, you know, a mission that, you know, I find very impactful and something that excites me. And in some ways, I think, like, you know, the vision for our team has not changed, you know, with the acquisition. I think we've been able to do more, you know, by, you know, teaming up and, you know, joining forces with Red Hat. And so that's kind of how I thought about it. But, you know, I think we're still in the early innings of this sort of like, you know, huge shift, paradigm shift in terms of how security is handled. And I think it's really like, it was like, the catalyst was CUBE and containers and sort of all these like technical innovations. But I think like, what's really going to be felt over the years to come is kind of like, you know, more time freed up, you know, better security productivity, like all that stuff that's very, very hard to, you know, kind of, it's not as concrete as like, you know, some kind of like technical advancement or something like that. So what are you excited about? Well, let me ask that question later. What should we be thinking about for the future? Right? Like we are in this cloud native space. We are consuming cloud services left and right. Some are SaaS based. Some are actually like, from big hyperscalers, what does the future of, you know, security look like to you? Yeah, I mean, I think, I think CUBE security ultimately is not really about CUBE. And the reason I say that is like, you know, I mean, I think of, I mean, other people have said this. So I'm co-opting it and I'm not claiming as my own. But I think, you know, people have said like, you know, CUBE is a platform, you know, upon which platforms will be built, you know, and you started to see that, right? You started to see that with like service mesh SEO and like dependencies, you know, in CUBE, you know, custom resources and everything like that. And so I think the way people like actually consume, you know, compute and, you know, sort of like the abstractions that they run, like their apps on are going to be built on CUBE. But like who's going to be kind of like, you know, lower in the stack, kind of maybe, you know, hidden away or abstracted away and things like that. And so, you know, in my mind, I think of things, you know, moving in the direction, you know, to be higher and higher level, you know, and I think there's a sort of like, you know, notion of security as code, which is like a very general thing. But to me, like what that means is like, it's simply aligning with like that movement in terms of the extractions. It's almost like, it's like, you know, if you could think of like serverless as like, you know, an operational model where like, you don't have to worry about all this stuff, like there's some kind of like analogous term, you know, maybe, you know, maybe we should think about what that is. But like, there's some kind of analogous term where it's just like, security is also going to be abstracted, it's going to be codified. Securityless. There you go. That wouldn't terrify anybody. Um, sorry, that just popped out. Please continue. You might not be able to. Who knows? I just think that it's, it's something where like, it's not going to be, you know, if you have, if you've integrated it correctly into the platform, you know, the data focus is not going to be on like tuning some kind of, you know, kernel level component or something like that, right? Like, you're going to want to, you know, the user's going to want to specify, you know, a policy or, you know, some kind of artifact that, you know, captures security and codified form and have that, you know, applied everywhere. So it becomes like a security abstraction that people will interface with. So, you know, it's funny, you started off that, the whole statement of, you know, what's next in the future. It's like, Kubernetes gets a lower in the stack. We build on top of it, that kind of thing. And Dr. Richard, I cook. He's known throughout the DevOps community, DevSecOps community, you know, and as well as, he's an anesthesiologist. He's also an incident response person. He's kind of like this magician of things, but he has this concept of above the line and below the line. And the below the line stuff is where Kubernetes is going to live at some, some point. Somebody still has to understand that and then build on top of that. But if we can auto, like Kubernetes gives us a capability of automation that we haven't had before. When you think of it being below the line now, how do you see us getting there? Yeah, I mean, I think, you know, there are others out there who have, when I think about like below line, you know, above the line, especially for security, like, you know, people, a spouse, like shared responsibility and like stuff like that. And like, I, you know, I think, and this is like, there's delineation, which is like infrastructure and applications. But I think the thing is, is like, that's getting, that's getting blurred. Yeah, it's getting fuzzy. Like, I think, I think, you know, how things evolve over time is, you know, you end up starting to encompass more and more about your applications. And the reason is, is because like the pieces, you know, that you're using to run your application, like let's say in a serverless environment, like are smaller and smaller. And so, you know, I think that, you know, you start to, you know, take on, you know, more and more of that. And the line almost kind of, which was sort of like somewhat of an, somewhat of an artificial line, like ends up going away in my mind. Good point. Very good point. It does eventually end up going away or automated away, right? Like, yeah, you know, yeah, we don't have an it script anymore, we have system D, there's some automation there. Say what you want about system D, I don't care, it's part of the operating system now. But like, you know, that's an abstraction. And we're not worried so much about stuff below that anymore, we're worried about system D. Right. There's going to be more abstractions like that with Kubernetes, I think in the future, right? And, you know, of all the development platforms that people have tried to build over the years, I think Kubernetes gives us the most stable foundation we've had yet to do such things. So I'm excited about the future. What are you excited about, either next month, next quarter, next year? What are you most excited about? Why I'm genuinely curious? Well, you know, I mean, if you're going to point to kind of like, you know, next couple of months, look, I'm super excited about KubeCon, right? You know, KubeCon, and we actually will be at Cloud Native Security Day two, but you know, just chance to congregate again. And it's kind of this like hybrid event, but it's really great to see, you know, people being able to like reconvene in person after, you know, I think that's, I think it's so important too for the community. And look, I mean, like, we have globally distributed community. And I think one of the great things about being open is that you can connect like wherever you're, you know, regardless of wherever you are. But I do think there's something, you know, especially about, you know, catching up in, you know, in person with, you know, folks, you know, who you have been, who you've built relationships with, you know, online offline, and being able to do that in person, especially after, you know, last year and a half we've had. So I'm pretty excited about that, you know, meeting folks in LA and, you know, seeing familiar faces and again, like, you know, talking about where we go with security from here. Right. And it's been so long since we've sat down and had like that conversation. We might all have very, very new stories to tell and share and different perspectives too, compared to the last time we all sat down and talked. So I am also looking forward to KubeCon as well. Is there anything else you feel like, do you want to talk about cheesecake or not? I mean, you can normally it's our icebreaker question, folks. So like we asked, you know, cake or pie is cheesecake a cake or a pie? Wei's answer is very, very, you know, interesting, I think, but feel free to talk about anything else that you want to bring up. Well, I mean, you know, since, since this is going to be recorded, Chris, I feel like I should get my response, like just on the record. Yeah. I mean, I mean, first of all, cake or pie, you know, someone with a sweet tooth asked like, you know, like, why not both? Like, why question? But, but, but yeah, you know, I mean, so I'll leave it there. But, you know, on the cheesecake or pie thing, like I'm going with Alton Brown, like it's definitely a pie. Yeah. Okay. Fair enough. I just say it like definitively like that. Okay. Drop the mic, walk off. Cheesecake is pie. And in my opinion, I'm kind of with you, right? Like, doesn't matter. No, I'm not really going to eat it regardless. But yeah, it's, you know, it's a thing. So Wei, it's been great talking to you. Is there anything you wanted to mention about the roadmap for ACS or anything coming in the future product wise? Yeah, I mean, I'll stop my head. So yeah, well, you know, I mean, I will, you know, actually, since you give me the option, I will take a just a couple of minutes because I think like, you know, since the acquisition, a lot of people have asked, like, you know, where are you going? Like, how's the roadmap changed? You know, how do you continue to innovate? And so a couple of things I'll point to, like just on, you know, things we've been delivering since the acquisition happened, which was in February. And we have blogs and resources, you know, available about this. But I think, like, it's been great to see us, you know, put out, you know, certain capabilities that allow us to tie more into the OpenShift portfolio. You know, we have ACS operator, we have, you know, vulnerability scanning certification for ACS now integrations with parts of OpenShift. So things like, you know, compliance operator integration and things like that, that will give you more seamless and consistent experience across OpenShift and ACS. And of course, that also, you know, I'd be remiss if I didn't mention that ties into OpenShift platform plus, which is, you know, it's a new bundled offering that ACS is a part of. From a roadmap perspective, I think, you know, there's many things to highlight. I think one area I just want to, you know, call out as an area that we'll continue to, you know, build into is managed services. So, you know, Azure OpenShift, you know, Rahat OpenShift on AWS, Rosa, you know, OpenShift dedicated, you know, all those models, like I think you asked about, like what does security look like in like CUBE environments and like the hybrid cloud? I mean, you know, getting consistent security, you know, whether you're on something like OpenShift and, you know, Rosa Aero or whatever else, you know, is really important to us. And so, you know, that's going to be a commute area where how people consume ACS is going to become easier and easier over time, you know, regardless of whatever environment they're on. But we are on operator hubs, so you can take our operator and, you know, use us today and we'd love to hear your feedback. Exactly. All right, Wade, thank you so much for coming on. Really appreciate your time today. Thank you everybody for tuning in. That tuned in live. Thank you for watching this after the fact. If you're watching it later. It was great talking to you today, Wade. Don't be a stranger. We'll meet up at CUBECon. Maybe have another conversation about that. Likewise. It was great being on Chris. Thanks so much again. Thank you very much. Appreciate it.