 Welcome to the next, what is this? We're in March. March, Stack Rocks Office Hours. It's a great big office hours joined by Matthias and Jamie from, well, Red Hat, but formerly from Stack Rocks. So excited to have them on. We're gonna be talking about the future of Stack Rocks and the open source project. Thank you so much for joining. As always, it's the third Tuesday of every month at 4 p.m., well, it was Eastern, but I lost an hour of sleep over the weekend. Wasn't exactly ecstatic about that, but yeah. So every Tuesday will be, or every third Tuesday of every month, we'll be talking about the project as well as anything security in the open source world. We'll have some guests on. Last week, we were talking get-ups and get-up security with Christian Hernandez, which was awesome. And I look forward to having future conversations, but I want to introduce my guests, Matthias and Jamie. Matthias, bring yourself in. What do you do at Red Hat, and then we'll talk about the project. So hi, I'm Matthias. I am a software developer in the ACS team. So basically, the team that is developing the main project that will now be open sourced. And I've spent the recent time, basically, with providing the engineering support and the know-how, basically, to open source the project, ideally. Awesome. Jamie, what about you? I am Jamie Scott. I'm product manager for Advanced Cluster Security. I came over with the Stack Rocks acquisition. And I spend my time between working with our engineering team to interfacing with our customers and the general security community to advance Kubernetes security. That's awesome. That's a great tagline there. Jamie, doing a lot. Yes, Billy the platypus. I'm hoping that we standardize around something because I don't like the flip-flop in the spring, especially. But let's just cut to the chase. The reason we're here, as Matthias kind of alluded to it, Stack Rocks will be open sourcing in T-minus two weeks, 15 days, March 31st, a Thursday. Software will be open sourced. The GitHub will be available. Public images will be available on quay.io and we'll be sending out a bunch of information for y'all if you want to check it out. We're super excited. And this is just kind of a soft drop. We wanted to discuss engineering requirements, the meetings that are coming up, and give everybody in the chat a chance to ask some questions so that we can get some feedback and make sure that you guys have everything you need come release day. So thanks to y'all for joining. Let's just go over some of the critical stuff I think that we've put in motion. Matthias, over the last year, and Jamie, we got acquired last February, I believe it was. There was the official date and since then there has been a big commitment to open sourcing Stack Rocks and it started with the Stack Rocks.io website. For those in the chat who don't know, Stack Rocks.io website will have everything you need for the project. All the links we posted there come March 31st as well as an update and a blog to kind of get you started on how to move forward with the project. So that's a lot of the stuff that I've sort of been working on is the website. Now the underlying things that you guys have been working on with the GitHub repository and Quay, hopefully you guys can give me some insight into what it takes to open sourcing something like that and getting an open source project on GitHub and Quay because it's been about a year since we got acquired so a lot of engineering work has gone into it. Matthias, hopefully you could shed a little bit of light. Yeah, sure. So what happened? Basically as soon as we got acquired we started working and organizing on or thinking basically on how we could open source. So the problem is always doing commercial development versus open source development. These are very, very different things. So how do you transform a project that was private in the first place to something that is open and that everyone can work on? So that took us quite some time actually because we already planned out or we spent a lot of time. Of course, there is always the legal side. There is the side of the company and all the regulations. And I have to say having experienced and seen this project grow from basically from day one was very interesting because Red Hat was very supportive and let us do our thing how we imagined it. We were able to build an open source project how we liked. They supported us in everything we did which is something that I personally really enjoyed doing. So the most interesting thing for me is we did plan for the community from the get-go which means I'm happy to announce that we will be doing monthly engineering meetings. So we will have Stackrocks office hours which is what we're doing now. And then we will also have engineering meetings which are a little bit more focused on the community interaction on the product side or on the engineering side. So these will be taking place every second Tuesday or no, every second Tuesday of the month at 9 a.m. PST or 5 p.m. GMT wherever you live. And what we'll be doing there is doing a little bit of announcements more for the technical side. So breaking changes, new updates, new features and also we'll be talking about feature requests or any issues that the community has encountered. So we're not only are we open sourcing the product itself, the platform itself, but we're also opening engineering a little bit as in we're open for discussions, for requests, for problems. So we have an open year for everyone. And I think it could be as simple as hey, I'm trying to get started with the website, maybe the documentation's not clear, maybe the images aren't as accessible as we wanted to. We're looking for all feedback, all in any feedback. I think these meetings, right, Matias? Yes, absolutely. So be it that you have questions regarding the documentation, be it that you have questions regarding the architecture, or even that you would like to see a feature or an integration. That's all things, basically all things engineering, all things that you use. We're happy to talk about it. We're happy to hear your feedback and change and adapt where needed, of course. We've got a large number of customers who've asked us repeatedly, how do we create a community of policies stored? And how do we change and understand where changes in our policies go from this is reasonable, this is what we would expect, something more hardcore? We've got a lot of customers who are even doing things like putting large lists of crypto miners together and using those in order to do attack simulation. And I'll give you a quick example. We had a customer who had the ability to put in Docker images into one of their platforms and they were actually looking for their users who were adding crypto miners, getting community solutions like this together so that we can add and improve our policy set for our entire customer base, but the entire Kubernetes community as a whole. Really something that I think will power the community forward. Yeah, we've seen solutions like OPPA have a bunch of advantage to using something like that, right? Typically there's a very small group of security open source platforms. And I think that's a relatively new thing. And so obviously sharing policies is one of the advantages. I think community feedback is one of the great advantages too. And in the recent log for Jxploit, you saw how fast the bug like that got fixed. I actually almost think, you look at the time to CVE fix, Linux leads the way. Kubernetes, and that is in a very quick second, right? You're smiling right now, but it is kind of true, like these things happen. It is one of the advantages of my rod. Yeah, no, that's totally correct. And you kind of look at the CISA is known vulnerability is list. And you see how recently a lot of exploits have happened because of the war in Ukraine. And we see that there have been hundreds over the last few weeks that are really emerging. And I laugh because so many of those have been windows based. And you look at how the Linux community comes together for these in the open source community. And that means that there's a lot of visibility on those. So there's less reactivity that's happening and it's ongoing management. Especially beyond behind the scenes reactivity is also one of the big things, right? When a security provider that shall not be named maybe, I don't know if it's polite right now, but when it's behind closed doors, maybe they're less likely to be completely forthcoming with their customers about the breach of a hack, right? When things are open sourced, you get some great feedback whether you like it or not. And so that's I think part of the engineering meetings. And then obviously if you miss the engineering meetings on the second Tuesday office hours on the third Tuesday, we're looking for your feedback. Because I think as much as we're open sourcing a platform for teams and organizations and the individual user to use to secure their Kubernetes platforms, I think it's awesome to have just as much feedback. And I think it's just it creates a great ecosystem, right? That's the whole goal. So yeah, so second Tuesday of every month, which will be a little bit more, we're a lot nicer to the Europeans, I think with that meeting. It's 9 a.m. Pacific, 12 Eastern and 5 p.m. GMT time. And luckily I think that Europe changes, or at least I know England changes their clock in two weeks. So we don't have to worry about any clock issues. Once we open source on the 31st, which is kind of nice. And then again, this time, third Tuesday, next month for office hours. We'd love to see you guys there. In terms of all the locations for the critical stuff for the open source projects, I put in the chat, stackrocks.io. That'll be the website for everything you need. There'll be a docs link that's going to be put up. The GitHub repository link will be put up there as well, as well as a blog, just kind of detailing all the resources and everything you need to know. And of course, we're going to be sharing it out. You're going to see a bunch of links from the team. And hopefully if you're on LinkedIn and you follow Red Hat or any sort of that stuff, it'll pop up. You can also follow the RSS feed on the site for notifications. All right, that's all I'm going to tell you. Other than that, you've got to find your own way now. Now we're getting into all the stuff that we had to go through over the last year to put the project together. So Jamie, I kind of wanted to turn to you because especially you're so hands-on with customers and you've had sort of that high level view of what it takes to be open source. And also, I think all the requirements and all the, I don't want to say pushback, but just the engagement that you need, right? When you have a big user base and you have to say, hey, by the way, this product that you're using, we're going to go open source with the code. Are we for or against it, right? So there is that comment back and forth. What did you see last year? What's the push for open sourcing now? Yeah, so ultimately, when you look at our customer base, we actually are overwhelmingly for open source. And that comes down to three key questions. The most important of those questions being, how do you as the platform provider expect me to trust you in order to secure that platform? So you're giving me the guidance, but is that not a conflict of interest? And that's what we've heard from our customers. So open sourcing is our solution to establishing transparency. That's how we can tell our customers that this is our commitment to you and that we're doing the right thing by you. We're both going to provide you that platform. But we're also helping you to secure it. And Red Hat's commitment to security and open source really has led to that brand awareness that we're providing you packages, we're providing you a security solution. Security is really ingrained in our core values. And by the way, in order to prove that to you, we've open sourced our solution so that you can go and validate yourself. The configurations and code that we're writing to provide you a security solution actually secure the platform. And we'll tap into the community in order to really hone that down and use the community to hold ourselves accountable. So like a lot of feedback for open sourcing? Exactly. It's shocking because you don't see that many security platforms that are open sourced, a lot are behind closed doors. What do you think is just like, because you'll see small tools, right? You'll see things like Claire, like a security scanner be open sourced or something like that, but you won't see bigger platforms like a StackRock be open sourced. Why do you think that is? Yeah, I think that comes down to that's their competitive mode. So when you look at the industry as a whole, there's a lot of small parts of a solution that have been open sourced to drive innovation and to create adoption. But that's really a product-thought growth model in order to get adoption and bring your brand forward. Now, and it's also a way that you can validate your solution is appropriate in the market. The difference being that as a platform of open sourcing, you've got customers. We've been used and we are no longer trying to validate our solution quickly, which is part of the value of a company open sourcing. Their solution is quick market validation. But rather than trying to validate our solution, we're actually trying to establish transparency and drive innovation forward. So in order to do this, our aim is really to create a community behind Kubernetes and Kubernetes security so that we can secure the platforms and workloads holistically in the environments. And we can have a community of innovators behind us that are not necessarily part of any company that can drive us forward as an independent community. So the goal here is vendor independence. And also, how do you establish transparency there? So we've gotten a lot of positive feedback for open source, but really at the end of the day, I think that platforms choose not to do this because most of them are building cloud services or that's their moat of their core business. And because of that difference of quick market validation and established solution as a whole, that it's going open source, the incentives are really different. That makes sense. No objections here, Matthias? No, absolutely. So it's very interesting to see, especially... I've been approached by quite a lot of people that are interested in the open source product. So I'm feeling not only is it... Of course, the competition is hard, but also on the other hand, what I'm seeing is that companies are interested in open source because on the one hand, not only is it adding accountability, so you can see what is happening, but also as a company, I can go look at the source code and I can see what is happening. So we're not hiding anything. So we're not giving the impression that we're hiding anything. And also it allows us to not only show what we're doing, but it's also giving you as a customer, or basically we're reaching more customers, we're reaching more potential interests or we're reaching a wider audience of people that are interested in not only getting maybe, maybe not only having a look at our product, at our platform, but also growing, as Jamie mentioned, growing the holistic Kubernetes security area, basically. Especially when it comes to Kubernetes security, I was, as I kind of mentioned, there are these small projects, right? There's OPA or there's a FALCO, right? But the Kubernetes platform, the whole security platform, if you're gonna go secure Kubernetes, you have to kind of piece together all these solutions if you're taking about open source, right? So it's a lot harder to operationalize in that sense. And basically giving, here's a full Kubernetes security platform for you to use and take advantage of. So I'm pretty excited to see that part. For everybody watching, we got a good sizable people throw some questions in the chat. We're interested to hear, do you plan to use it? What are you looking forward to? Anything that you are skeptical of? We'd love to have that conversation, especially as we get into more engineering talks. This is, Mattia's a segue to get into, just, we've had bi-weekly meetings for last year to talk about blockers and all the different considerations. And you would be, I was shocked at how much work goes into something like this. And not just open sourcing, but open sourcing, I guess in a way that can hit the ground running for most people. Cause really technically open sourcing, you just have to drop free code and a binary on GitHub. Am I right, Jamie and Matthias? Technically that's open sourcing. So a lot more work that goes into it. I'm super happy that we got to keep the StackRox brand and StackRox name alive, right? Anyways, Matthias, how did the journey start, especially post acquisition engineering meetings, what were some of the considerations that you could share and the different hurdles that you had to jump through? I mean, we primarily started with reaching out to legal because especially with branding, with the name, with logos, there is a lot to consider also source code, of course, in the meat of the whole thing. That's something we needed to have checked and signed off by legal because I mean, we're still talking about a big project and better safe than sorry. But I also noticed that we started quite early with the whole thinking about how do we develop? What changes? Because for us as a developer, quite a lot changes. I mean, on the one hand, of course we'll be working on the GitHub repository. So this is staying the same, right? But on the other hand, there are questions like how do you handle CVEs? How do you handle security reports? Because there are things that you, there are things obviously that you can do in the open, but now you're completely in the open. So how do you do these things? That was kind of interesting to see. We do, we have developed a process for that. Basically, we'll be established secure communication channels where you can report vulnerabilities or basically get in contact with us, get in contact with engineering. And I'm also very happy to say that engineering isn't very, is never far away from community. So it's kind of easy to get a hold of us as engineers, which is something that I'm very happy about because sometimes it happens that you, no matter how hard you try, you never get beyond or get past maybe second level. I would, let's call it second level support. So it's hard to get a hold of engineering or of devs. What else did we do? Of course, the ongoing issue of documentation. So we have a lot of internal documentation about how we develop our product, how the processes around releases work. But the question is of course, now that we switch, do we open source all our documentation? Do we keep all of it private and just let people figure it out? And I mean, I think you already mentioned it. We have, we shared our documentation. We're open sourcing also our complete documentation and most of, no, all of the architectural documentation that we have. What else, oh, sorry. Oh no, that's exactly right. I was just gonna answer this question. Although Phillip, I did have some great feedback to the question. So from a business perspective, why is it important to have the option to look at code and why should I care? Yeah, so back to what we were talking about with some of the customer concerns. It's a sense of validation of that. You can trust the holistic platform itself. So for instance, you have a community of people that are driving forward, how your security posture will be managed over the course of your evolution of your applications. And if Kubernetes is being used to store a large number of your applications as we see the market shifting toward, that's gonna be your bread and butter. So how do you know that they're doing right by you and how do you go in and validate that? So yes, there could be backdoors, but also it's as simple as are the rules that are being defaulted and recommended that my team is using? Are those appropriate for my business and are those appropriate for the community as a whole? How do I know that, for instance, how do you know that Red Hat isn't making open shift? Look more secure. And you can go and validate that with open source code. Yep, yeah, that's a great point. That's a great point. There is also the being able to, let's say, go and deploy it on various different platforms. You can get a look at functionality, usability. You don't necessarily have to go and interact with a sales person. I can just go see if it works or not, which as a millennial, I think is probably one of the biggest selling points. I think for a lot of new technologies now, it's like, oh, I got a free trial and it doesn't even come with a paid subscription at the end, it's awesome. And I do find a lot of the times too, you get locked into these big contracts where you don't end up using all the functionality that you ended up paying for at the beginning. And so one of the other advantages just from a pure usability standpoint is I can go in and see how much am I actually gonna use. The more I use Kubernetes, does it fit in with my CI systems, my integrations, does it fit in with my SAEM tools? You can get to test all that out without ever having to, let's say, get on those hour calls with maybe they're a little intense time constraint, you can go and thoroughly explore it, right? I mean, piggy-begging on that, that's also something that we try to take a lot of care of is low, for me, one of the most important things is lowering the barrier of entry. So I actively fought for us to have darker images available where we can, to have docs, to have basically, to have open sourced as much as we can. So you can just go ahead and get started. So I'm not entirely sure about the image locations. Do we know about that right now? They'll be, yeah, they'll be located on Quaid.io on release, I think, community feedback and there's still some conversation about Docker, but would love to get some community feedback on if that's something they'd like to see. Still got two weeks before release and it's going to be a moving project after that. So look forward to all your feedback and you can come and join the Zoom meetings. It'll be a very fun hour. And of course you can always come hop on the office hours and give us feedback. All right, so we talked about, well, that was definitely number one, right? Legal branding, what's going on with that? And then when you got into the engineering aspect, now you have two projects. So you have a community project and then you have a red hat project. So now you're building two pipelines, right? Now you're talking about how does that get built? What systems do you build it with? How often are you gonna build? Are you going to ingest PRs and requests? How often do you vet those? What types of considerations came in from taking something that's an upstream project and then having to build it for the upstream and having to build it for the project itself, paid project? Yeah, so the interesting thing is for the paid project, of course we have a build process because we're actively releasing. So that sorted out. We're still in the process of figuring out how we can automatically generate images for the open source version for the upstream project. So what we're planning or what we're trying right now is doing automated release builds and maybe something like in the future have something like nightly builds or unstable builds if people are interested in that. So again, we're in this dimension, we're completely relying on community feedback. So stop by the office hours, stop by the engineering meetings, tell us. That's something we're quite open about. So of course we had roughly a year of planning right now and we have a rough idea what we want to do and where we are right now, but that's subject to change. So we're not stopping investing time and work and energy into this project after release. We'll of course continue developing and continue engaging with the community basically. So what we'll be doing is besides the CI aspect, how are we talking, let's talk about active contributions because that might be interesting to a lot of folks which is right now we're planning on having these monthly meetings. So the, and in these meetings, what we'll do is beforehand we in engineering will have reviewed the currently open pull requests and or feature requests basically. So the idea is if you hand in, if you open an issue, if you have a feature request or something like that we'll be triaging it in a short time. And when it's triaged, we will usually take that up with engineering, have a talk with our fellow with the team and see if we take that on the roadmap or not or maybe, or if we take it on the roadmap what happens with the issue if we want to take it, if the community wants to take it. So, and these decisions will be discussed in the month, the engineering meetings. So the idea is if you have an issue, a request, hand it in, we'll have a look at it and then usually we can chat about it in the engineering meetings. Awesome. And so the, at release there'll be a blog detailing all of the locations to get to but Matias is working on a more detailed blog as well that hopefully will have basically all summarized how to do a feature request and of course we'll go over this at the first engineering meeting to get things kicked off as well. Again, you can subscribe to communityatstackrocks.com the calendar and you'll see those public events. So any updates, you'll automatically get notified of it and then you can just basically click the zoom link and join the meeting. I'll be posting that as well in the chat and in the comments. So you can always check it out there. Jamie, wanna switch gears a little bit and talk about the Kubernetes security community specifically and why Kubernetes as a platform requires its own, let's say security touch, why you can't necessarily look and take maybe slightly, I don't wanna say outdated but an older approach and then bolt on security into Kubernetes like what has changed in the past six, seven years since Kubernetes has been adopted. So I wouldn't say that it's about a change in Kubernetes. I think it's about a change in workflow for the security organization as a whole. So as people start to think about shifting left and as people start to think about giving accountability for security to developers, we've really resulted in a world where there's a skill gap and it's not a skill gap that is reasonable to solve. So it's unreasonable to expect a developer to know security, to know the business use cases and to be able to code, that's just too much to focus on at any given point in time. So the reason why a solution is important is because it bridges that skill gap. The reality is that, and this is not true for everyone but in terms of the 80-20 rule, there's a lot of the security community who's learning Kubernetes still. And there's a lot of the development community that doesn't have that extreme security focus. So from an auditor's perspective, they wanna see exactly how something is configured. They wanna see, be able to validate if there are vulnerabilities. And the yaml behind the Kubernetes deployment is really the dream of an auditor. We've basically given an auditor a book with Kubernetes and said, this is the book, go read it. This is the exact configuration. Here are the images. And by the way, if you wanna go inspect the Docker file to understand more about the configuration, go ahead. The problem is, auditors have no idea how to read that book in general. And the point is to teach them how to read that book. At the end of the day, we need a community that can help bridge the skill gap, but in a way that as Kubernetes is advancing so quickly over the last seven years, and it's really hockey-stipped in terms of its adoption, we need to be able to create a community focused on engaging in Kubernetes security because the simple reality is that it's a different way of working and people are still trying to catch up in a large number of the world. Yeah, there was, speaking of hockey-sticked, I remember talking about, I think it was project adoption. Argo CD was one of the biggest adopted in the last year. You look at, when they look at what the biggest requirements of teams are, security was number one. Finding good talent, I think, was two or three in the Kubernetes world. And yeah, it's very interesting. I think you have a lot of maybe tools that are trying to be multi-platform, are trying to do containers and virtual machines and have all these integrations. And it's just a very difficult thing to scale, right? And so it might be something where, hey, you know, you have this big project, this big contract, maybe you try out Stack Rocks from a team to team basis, do something greenfield, see if it works for that workflow, right? There's a bunch of different ways that you could use it, especially an open-source project like that. It's pretty exciting at that level, right? Just to, I mean, that's basically how I got started in Kubernetes, had a server, set up Kubernetes, did Kubernetes the hard way, thanks Kelsey Hightower for that one, right? And then it's, okay, what applications can I go and install? All right, let's go set up Argo CD, let's go use Flux, right? Let's try Istia when it first got released and crashed my Kubernetes. Back in the old day in the service mesh wars of what was it in 2018, that was always the very interesting thing about it. And I think you're just now starting to see widespread adoption because that security expertise is starting to catch up, right? Because customers are starting to feel like they can secure these platforms and manage risk accordingly, whereas before they were a little unsure. I mean, I remember I used to go into some customer calls and they'd be like, hey, Kubernetes, it's great, especially containers, containers as a solution, it's awesome for developers. But then the higher-ups are like, I have no clue how to secure this thing, how do we start, right? So nobody's gonna agree on a project like that, right? I kind of use this as a proxy. How many security people do you know who exploited or remote code execution vulnerability on a container running as room and then picked up the default service account that was auto-mounted and then tried to use that in order to get access to the Kubernetes API? That's really an incredibly simple thing to do if you first are able to find that remote code execution vulnerability. But if people don't think I need to take these steps to secure and defense in depth is a thing, then it's incredibly easy to do those things without a firm understanding. And most security people don't have that hands-on ability to think from an attacker's perspective and then translate that into a defense that's in a way that's tool-specific. And they're learning that for Kubernetes because Kubernetes has gotten such widespread adoption, but it is still in the learning phase. Yeah, and I think the thing too is you have probably what one security team, maybe a couple of security teams for each project spread out. How do you get that information to the rest of your teams? Because the developers are gonna vastly outweigh your security team at most organizations. So you need to do that in an automated way that's team-specific because they all probably have their different way and different pipelines and different tools. Some are gonna have more crown jewels, very maybe databases that are gonna have different standards versus your stateless containers that are gonna be in Kubernetes. So a lot of different requirements. And you're asking a security team to develop all that policies before they even know what tools the developers are using, right? It's a tall ask. This is simply a numbers game. Look at it this way. In reality, there's probably 100 to 200 security professionals at a humongous organization. So thank your fortune. But that just doesn't scale because they have so many developers and so many projects. There's no way to keep one, teach all of those 200 people how to do Kubernetes security in depth and also expect them to know every database, every web proxy server, every service that is potentially being used in the environment. So it's just an unreasonable ask in a numbers game. So you can have a specific number of Kubernetes security experts, sure. But you're not gonna scale that number of Kubernetes security experts to every development team developing on Kubernetes in your organization. That's just in general an unreasonable ask. How do you find a platform like Stack Rocks is best implemented? In what way? So yeah, I guess it is a tall task. Let's paint a picture for you. You have one security team, four people, five other teams, all slightly different build processes. You're gonna go and deploy Stack Rocks. What's the general workflow? Like is it a deploy, visualize first, kind of take in information and then sift through, setting baselines, what's the general workflow for deploying Stack Rocks? Yeah, so it depends on where you are in your life cycle of adoption of Kubernetes and creating new workloads at the end of the day. Now, if you don't have security baked into your Kubernetes clusters, then it all starts with visibility. Security teams need to establish visibility in their organization. And they really have a wildfire of this is green space and I need the visibility to even know where to start. So you start with visibility, you take your highest risk potential workloads and you start from there. But then you also need to start proactively kind of leading. You wanna make sure that new projects and new workloads coming into your environment are meet your security standards. So people start first with the visibility and understanding where things are from a core set of best practices. And then they move in their immediate next step is I'm going to define policies. What are my expectations of my development teams? Because without setting those expectations and communicating those expectations, it's really just a non-starter to say, go do all the things to a development team before you define them and expect that I'm gonna change it in the middle of your sprint and you have to adopt to this. But so we realize human behavior is a thing and that people need reasonable expectations. So setting those policies, communicating them and cutting the bleeding by asking your development teams, hey, start testing this in CI, look for vulnerabilities in your images on new projects, look for misconfigurations in your deployments according to this policy set of new projects and then really going through and prioritizing and cutting the existing workloads. That's how most people approach it when they've already adopted Kubernetes. But if Kubernetes is green field, you start with defining those policies and going from there to ensure that those policies aren't here too on a go forward basis. It all depends on where in your life you're deciding what Kubernetes adoption is on. Yeah, I do find there's two kind of camps with Kubernetes is one is develop as fast as possible, get your CI process and then bring in security to sort of work within the guidelines or there's bring in security here, the kind of strict guardrails build within it and then we can slowly open up as there's not open up but the policies become a little bit more, I'd say set in stone and things start to move faster as you get by in. I find that there's kind of two approaches. Do you find the same? Mike, I don't know if it's just me but I didn't hear where you just said. Ah, no. I definitely just cut out for a second. I'm supposed to have good internet, what happened? So I think I heard you. So the thing is, you, sorry. The thing is- Where was he cutting out? I don't know exactly what happened. So thing is, you can, of course, you can either have security come in after the fact, after the development or have security come in first thing. So the question is, and the nice thing about StackRox is you can do both. So you can start rolling it out when you're already a little bit later in your life cycle and start with the reporting or you can start by basically deploying your cluster and the first thing you do is roll out StackRox and then define policies and give people guardrails and security rails that they can basically break out of. So you can go both ways, which makes the platform itself very, so as the platform itself is very flexible, it's great to have these. Yeah, no, I- It's all about sending them- Go ahead, Jimmy. All about sending those guardrails for people to innovate and that's why policies are usually the first step because once you define those policies, you have an expectation for your development team that you can communicate. You can start to block things in an emission controller, but also from an instant response perspective, your security team, once you've defined those policies and what you want, has something where they can go in policy violations when they log into their platform on a Monday and know how to start triaging their Monday morning based on those policies. Please make sense. Any more questions from the chat? Jamie, I think it was you that are having the internet issues. This is the first time I've had on stream because I'm in Toronto and we have Jamie out in California and Matias out in Europe. So this is really stressing the internet here on this call. This is a lot of fun. Thanks for coming on you guys. Some last questions from the chat. Otherwise, I think we're just gonna go through, basically make sure you guys have all the information you need coming up on March 31st. March 31st? I don't know the exact time. I think it's gonna be like at midnight, like super dramatic midnight Eastern time kind of drop maybe or something like that, but there'll definitely be an announcement the day before for all you guys. And of course, actually I'll post, there's a Slack channel as well. It's in the CNCF Slack, just hashtag StackRocks. There's a bunch of former engineers and engineers that actually work on the project already that are extremely happy to answer any and all questions that you post. And if it's something that we wanna do a Discord chat or I think we're up for anything Matias, right? We're hoping that you guys come on to the Zoom calls and give us your feedback, what you'd like to see and how you like to deploy the project. Any last comments, Matias, Jamie? Honestly, feel free to stop by. I guess we'll start with the Zoom calls, but if community demands that we, or asks that we move to something else, I'm happy to set up anything that the community is interested in. So again, keep coming by, keep the feedback up. Just drop us a line. See you guys. I'm looking forward to this actually. I'm very, very hyped actually. It's been a long year, right? I think we've all been getting on these weekly meetings. All right, what do we gotta do? What do we gotta do? And then it's, hey, here's this crazy blocker that we didn't consider. Matias, did you guys ever remove the cat picture in the pull requests or? I don't think that we cleaned these. So I think we had quite a lot of spring cleaning in our pull requests and git history, but I don't think we ever cleaned out the cool gifts and the weird gives. And I mean, again. Are there any Easter eggs in the open source project? There's a lot of cat memes. There's a lot of cat memes and gifts, yes. As long as there's one grumpy cat, probably like in the compliance section or something like that. Oh, I put a grumpy cat in like every one of my release pull requests. That's too funny. There's a lot of them. I'm trying to think, if we did do an Easter egg, what do you think we should do? We need a community Easter egg. We need to put one in. Anyways, join April 12th, first engineering meeting and you can pitch some ideas. Absolutely. Yeah, definitely, that'd be awesome. All right, Matias, Jamie, thank you so much for joining. Everybody for watching, thanks again. Office hours, third Tuesday of every month, 4 p.m. Eastern time, 1 p.m. Pacific. Open source, March 31st. If you go to starcrux.io, you can join the RSS feed or I'm sure if you're on LinkedIn and you follow anything tech related, it's gonna be on there on March 31st. Let us know what works, what doesn't. We're so excited to get your feedback and see you at the meetings coming up next month. Take care and have a good rest of your night, afternoon and maybe some people are waking up in the morning, but take care, everyone. Take care.