 Good morning. Good afternoon. Good evening wherever you're hailing from welcome to a special cube con EU edition office hours today We are talking about the future of stack rocks and I'm going to hand it off to the one and only Josh Burkus from our open source program office Josh Hey there So this is actually been very exciting as People watching probably know red hat acquired stack rocks for this year We have with us Michael Foster and Chris Porter from stack rocks who are going to talk a little bit about what they have been doing since then and about some exciting plans for the near future and Maybe even a fancy new website So Do you want to introduce yourselves and and what you do first what you're You're maybe your title and your old title and your new title Yeah, sure. Hey, thanks for the intro. That was pretty spot-on on my foster I was a cloud native advocate at stack rocks and now I got diet product marketing title at red hat. So Excited to be here. I'm looking forward to doing more technical content specifically on the stack rock side a little bit more So yeah, Chris go ahead And this is Chris Porter I was the director of solution engineering at stack rocks and now I'm the director of solution architecture at red hat big change Yeah, it's been a roll Been a fun change. Yeah, and Josh you nailed it. We're just looking to to talk to you about, you know What's changed the last couple months talk to you about community? First I think I can hand it over to Chris because I know we want to go over some changes What's happened since stacker rocks been acquired a lot of new functionality that we've added and hopefully open the floor I think to some questions Great sounds good. Yeah. Yeah, let's start with that If you're familiar with stack rocks is a software company, you know We focused on Kubernetes native security and I'm really that mission really hasn't changed We have always supported the enterprise Kubernetes platform the Openshift platform from red hat But a few customers using that today across, you know enterprise government For for our customers, you know, the stack rocks product is really about You know about that the Kubernetes native nature of it, right? So it's a security product, but it's also Kubernetes native and you know the thing that we hit upon here at stack rocks was that You know this product can Not just work with Kubernetes It's not just a container security product that happens to work with containers on on Openshift But rather like actually leverages the platform So I like to talk about this in terms of you know What the developers get like the advantage of choosing security through this approach means that you get to preserve the power of the Openshift platform, right this cloud native development and You know that the insensitive security products that are out there that deal with virtual machines and other security Topics just kind of miss out on that opportunity like we love the flexibility of the platform On the other hand, you know the security team has real concerns, right? When you give a lot of the power to the developers, there just needs to be a little bit of oversight, you know that We're trying to make make both sides happy here There's often conflict in organizations between, you know, the go in a million miles an hour new development cloud native But at the same time, there's a security team that's kind of you know, hold the brakes here to say hey We've got to make sure this is all secure before we go out into production or we have You know, we have compliance concerns that we have to to address, right? There's got to be an adult in the room who says hey, we have to make sure that we don't arise and cross our T's here So, you know at Red Hat, it's still the same product that you hopefully know and love the same focus the idea here is a product that is, you know reliable and And and, you know, kube native right making use of the capabilities that the platform provides Versus trying to introduce a separate set of controls If you like I can I can show you what it looks like and we can talk about some of the changes that have happened in the last few weeks And bring it up so if you're currently a user of the Stack Rocks product or if you Are new and if you've seen the demos even very recently even within the last couple of weeks you'll probably remember the the Stack Rocks logo and the blue coloring but One of the biggest visible changes that we've made is to put this in line with the pattern fly logo and and colors that OpenShift uses so for OpenShift users This will be quite familiar the same as the you know, the Red Hat OpenShift dashboard here, which we'll get into Just really to be in line with the you know, the product standards that are met here Because Stack Rocks is always operated on an agile Kind of development model. We'll have new releases every three weeks, right? And that that cadence has been kept up for the last few years here It means that we can make environmental changes. We can rapidly roll out, you know, fixes and updates and and accommodate new new feature changes from From product management or from customer requests If you're not familiar with Stack Rocks Well, you know overall the product is here to help the security teams get what they need out of application security, right? It's visibility. It's understanding where common security problems like vulnerability management and configuration risk exists in the environment It's about runtime monitoring, which is an extra layer of detail. That's really kind of hard to get any other way If you're a developer this interface is you know, certainly interesting I think provides a lot of insight especially when it's hard to dig into things like networking to show you, you know What what your microservice applications relationship to each other are? But we really don't want to force you into another interface, right security teams have their tools Developers, let's say they don't really like most security tools, right as a developer I don't want to have to go into some log somewhere else and I want to have to go open up a ticket and Investigate why my deployment got stopped what I want to do is work in the tools that I'm accustomed to using, right? And maybe it's a pipeline here in an open shift and you know, I'm using this to build and deploy my applications So if I've got a security issue, I've got a vulnerability or something. I want to see it here I want to be able to like on demand Like request the of a check from the security team to understand what I got to do to get this thing through the compliance gauntlet Right, okay. I got to create a non-privileged user account. I need to specify a CPU and memory limit So what I'm doing here is really we're trying to try to forge that that dev sec ops culture the idea that everybody has a stake in this everybody, you know has this Requirement or you know a desire to build applications that aren't going to be an immediate security risk And if I can do with the tools that I have and it you know as a failure that's spit out to me in an understandable way I'm encouraged to go out and resolve that right, especially if I know, you know in particular I've got You know particular library and I know there's a new version You know, I'm not being asked in this interface to go out and fix, you know The dex's LT right we're busy box. I'm being told that hey upstream has a fix that that I can incorporate that resolves a really serious Vulnerability, right and that's an easy thing for me to do. I Mean what I like about this is that honestly as a developer I've got a lot of different choices here as to what to do with this You know, maybe I don't need these libraries and I can go and remove them from the base operating system I'm using it by container inches right if it's not there I don't have to maintain it and and securities then is going to stop bugging me about this if if I can switch to a different base image, maybe go to a More minimal base image that doesn't have all these utilities then, you know, maybe I'm better off anyway so the idea is We've empowered developers with this control over the infrastructure, right of driving the application Requirements being able to make changes right that agility that gives me a quick resolution to the problems That that same agility of flexibility here is what we want to do for security, right? It's really about saying hey open shift is a great platform for running applications on and handling infrastructure It's also a great platform for security So when we talk about things like vulnerability management, right minimizing privileges and other configuration issues restricting network access Everything here is done in that open shift shade, right? So, you know, vulnerability scanning is one of those Towering topics in security. It's a never-ending problem, right new vulnerabilities being discovered all the time What we're trying to do here is provide the security team with some idea of where the priorities are now this one here This demo environment is is a really bad It's full of these old fixable vulnerabilities, but you know, where do I start to tackle this, right? This is often an overwhelming problem for organizations to understand like Where do I start with this, right? Especially if you bring stack crux into an environment that's, you know, well on its way, right? Like we're ready to go to production with this app or ready to launch and You bring this in and you look at this list of these vulnerabilities It seems like an impossible task and and we sort of agree here, right? Vulnerability management is one of those things that's necessary to tackle, but it's like only part of the picture so What stack was really pioneered was this idea of risk, right that because of the declarative nature of a Kubernetes application We know things like what kind of privilege levels does this have, right? What kind of network exposure does it have and all of those decisions that are being made by the developer, right? To expose a port or to, you know, run a privilege container or elevate, you know Some some kernel capabilities here Or my favorite down here on the bottom run everything as a cluster admin on the roll attached to the surface account like all this stuff has an impact on security and So by changing those settings or by taking a recommendation to say, you know, you really should be careful about running cluster admin That's not something that we would expect to see The system should not allow you to deploy this if you're trying to run You know cluster admin or exposing a privileged port like 22 You know, we're pushing back on the development teams to say, hey, there's a better way for you to approach this, right? Don't use X use Y You know, if you're running as a as a root user or privileged user account There are ways within the infrastructure that you can go out and and you know set a less privileged user account So some of the recent things that we've done if you haven't seen the product recently We're now looking deeper into some of the Kubernetes API so we can see when one of the users in the environment for example is Executing into a pod, right? This means that they're like administratively accessing a pod and You know really useful, right? It's it's something that we want teams to be able to troubleshoot their applications, of course but then security needs to know that Someone on the DevOps team has administrative access to you know, in this case potentially a sensitive application that has payment cart data Right and right there that's going to violate a compliance that are like PCI, right? We have to have You know even our developers, right? Not be able to access that kind of sensitive private information Because you know an insider threat or you know worse yet the fact that one of my Developers can exec into a pod and run commandants means that there's there's that interface available for potentially for an attacker One of the cool features that I think we talk about a lot here because it's well, it's cool Right is the networking part of this and this is usually where our security team Realizes that they're they're missing out on what's going on in these clusters, right? This spaghetti mess here is You know is a diagram of all of my namespaces and my deployments and it's showing me, you know What we're observing in terms of the traffic so really eye-opening because You know Kubernetes applications tend to get more complex over time. I add services I'm I mean deprecating certain services, but the pods are still running so this gives you that bird's-eye view of what's happening and you know, what tools are communicating with what but You know, this is a diagram that shows me You know all of my all my clusters in one place But more importantly, we're trying to to you know, give the hint to the security team about where the security risk wise, right? I've got this front-end environment and somebody's running, you know a WordPress site here if somebody compromises that The the problem here is that I can get further right the attacker can move laterally within the environment and That's not a new problem, right? That's segmentation. That's firewalling. It's it's a traditional problem in security and one of the big topics What's challenging here is just the nature of OpenShift and how that that firewalling is done And we see a lot of solutions out there in the marketplace that have gone and well They've built a container firewall, right? They have gone and created a solution that works on on containers and operates it the node level or at the container level and it solves the problem right the problem The problem with that solution to that problem is are you going to be able to live with it? Right. Do you want to have to to care and feed? You know this this little firewall running in your containers Are you willing to to put up with that and and we're betting that most people don't right? So what we've approached this problem from is that for all of my clusters here, you know OpenShift has a capability of building these kind of segmentation rules. The network policies are the right solution, right? Now these are these are you know a part of the Kubernetes spec They're enforced in OpenShift by the container networking You know, but this is in line with what we're about, right? That there's a declarative approach to configuration that can improve security, right? This belongs in the code along with everything else and helps to define the applications Having your firewall rules in a separate product sitting off somewhere to the side Violates that idea that your applications are driven by a single source code base, right? So this is in line with with that model now over the years We've seen that network policy, you know, originally wasn't all that widely implemented It was incomplete but you know between Red Hat and the other major You know Kubernetes platform vendors this really has become the standard and we think that that's the right way to do it In fact that idea of you know, hey, go fix a security problem in the code is Woven, you know entirely throughout this right that when you have a problem with security, right? You've got a process where your images aren't getting up to date You're including, you know utilities that are useful for attackers like package managers, you know Our solution is go back to the code and fix the configuration that you provided that caused this problem in the first place, right? Or you know, maybe the problem is you didn't supply a configuration and unfortunately the defaults in In you know Docker images and in Kubernetes are often designed for For productivity, you know usefulness right like get things running right away Rather than thinking about the security now the good news here is with OpenShift This one's actually going to be a default the other way, right? The security default in OpenShift is actually that you can't run these things Versus vanilla Kubernetes where you can so you know OpenShift gives you kind of a more secure configuration by default It's a little bit more more suitable for that security-minded approach But still there's plenty of power that you can hand over to your developers That results in in them, you know potentially being You know building insecure configurations there awesome So is there yeah, is there anything else you want to see I can spend all day on this Could you just zoom in a little bit and just show people like the different panels that are on this on this way here and And will you're at it? We've had a couple of questions Yeah So I mean first for the sake of GoPro slow I wanted to confirm. So this whole interface and everything is this is all Now specifically requires OpenShift So the the the product focus is on OpenShift, but the technology compatibility hasn't really changed And so the goal is to to provide for customers that are using OpenShift for the dashboard That actually allows for them to to run this kind of oversight on on other Kubernetes platforms as well So, you know the configuration here The you know the rules that we're using are very focused on on Kubernetes You will see of course that there are some things that are specific to OpenShift, right? And some of the features will not be available on other platforms But the goal is from a single dashboard running an OpenShift that you'll be able to provide security for other non-OpenShift Kubernetes environments. Now the StackRox product has never had As as support as a subject matter You know that anything other than containers running in Kubernetes So you won't see you know cloud security topics You're not going to see you know perimeter security topics in here, but for containers in Kubernetes. Yeah, absolutely Okay Another question is What are the parameters for setting the risk level? What are the what are the different factors that get weighted together? Well, there's Somebody wants a list. Yeah a list so Everything in this product is really driven by policy right a policy means you know a set of criteria that we're matching a set of scopes That define what we want to look for that criteria and it comes with a whole bunch of built-in policies, right a policy really defines Some some conditions that we're going to be searching for in the environment and it's woven throughout the product here So the policies are what create risk You can think of it as you know every policy for example like this one has a low priority These others have medium priorities and you can think of that as a score and whoever scores the most Wins or loses in risk, right? So it's really kind of a summary of all the things that you're seeing here and the customizability comes out of that, right? You know, maybe I don't care about You know, let's say privileged containers running now I probably do care about that but let's say I don't care about you know package managers and others like I can remove those risk factors here You won't see that show up and you have control over that scoring Some of it is a little bit more built-in in other words. We take things like reachability as a risk factor Just because you've exposed a service, right? And I can actually you know search for that and I can look for that exposure level So that's not really configurable today, but it is something where You know, if you it comes directly out of a configuration that you've supplied, you know I've got these things listening on port 80 that's going to result in in a reachability score and and risk associated with that what I like about that is you know security Products tend to have this model of you know detect some condition based on some set of rules and then send out an alert and We can do that too, right? I can send out alerts every single time I find you know a vulnerability But you typically run into that problem where everything is security tools really noisy and everybody just begins to ignore it So there are things like this like cool features That are part of Kubernetes like running with a read-only root file system, right? So you get into the details of it This is a setting that everybody should use it right if you're on you're listening to this like There's no one setting that will get you a secure application But if there was if there was one shortcut, it's to make sure that your containers can't write to the file system This eliminates a whole class of malware, right the ones that are going to try to drop a payload onto disk and execute it It's it's one of the things that really shows you the containers are different than VMs, right containers don't have interesting lives They don't do lots of things But the problem is that this is something that can be hard to get to right if you're a developer if you're migrating an application from traditional infrastructure to To containers, maybe you're relying on on that although you shouldn't you shouldn't rely on your file system sticking around But it's useful to track it right it's useful for me to have this tracked in here as a risk factor Even though potentially today. I can't do anything about it, right realistic security is has to understand that The goal is to get better at security that being perfect right off the bat is not not possible So I might want to know about this It's a risk factor when I think about things like oh, you know I'm having some runtime activity that tells me somebody's running a shell in this in this deployment Like knowing that the shell is in running in there knowing that a package manager is running along with the writable file system. It's a pretty ugly combination of risks Even though I may not at this point be ready to go out and send out alerts that hey people are using You know that file system So useful to track for risk even if I really can't do anything about this today. So okay The I want to be conscious of time and I know there's a second Part to what you have to talk about today. Yep. Yeah One of so just in general one of the things I've always liked about stack rocks is it's like adherence to kubernetes Like standards right like it uses kubernetes components to implement its security Rule that's right policies and everything else right like from the beginning from day one You all have said kubernetes native and that has made me very happy And I'm glad we've acquired stack rocks now right like it literally feels like a hand-in-glove kind of situation Yeah, absolutely, and and there's a lot of good reason for that and to be honest It doesn't make everybody happy people That are used to to particular security responses like they're used to managing a firewall Independently from the application architecture, right? There's this dividing line between the assets that security controls and the assets that the developers control We're trying to merge that together right it's all one One source code base, you know if I had my way somebody somewhere from that security team is going to be a code reviewer in In the you know on that pull request, right? I want to open up a new port for my application That's a kubernetes network policy that that I've got a review that I'm going to change That's where the security changes happen and the other part about about you know using things like the admission controller That's built into open shift right as a security gate When we enforce that way, there's no confusion about what happened, right? Developers don't like security tools because they're often insensitive in the way they do this enforcement It's a black hole and my my apps disappear into and I can't figure out and can't solve the problem So so the admission controller makes you know, it's like hitting a brick wall, you know what happened You know immediately you have the information at hand that you can use to resolve it, right? Security is not trying to to create a situation necessarily that is hard to troubleshoot They want to clear communication of hey This is not acceptable from that risk perspective and I think that using the platform makes a lot of sense Your teams are going to be immediately familiar with it, right? It's not a new security action that takes place It's the same as if you made a syntax or and you know in a yaml file you're trying to apply same exact situation that occurs so awesome Thanks, Chris. Yeah, and just to take over a little bit because I know go pro slow was Talking about yeah interested in what they could get involved with so Just wanted to announce that with red hats obviously commitment to open source and a lot of the other projects that Red hat is open source stack rocks is going to be one of them So as you saw Chris demoed the stack rocks product, but it's now named ACS So that's going to be downstream of the upstream project. That is stack rocks stack rocks go in open source it will be upstreamed and Yeah, we're looking forward to everybody contributing I if Chris if you don't mind would you can you run to stack rocks that IO and share the screen because zoom is thrown a fit for me, so Which Chris Oh sure. Yeah, good boy Yeah for everybody out there if you want to check out the website stack rocks that IO is going to be the home of the open source project and We wanted to announce it to to Bring everyone into the community throw a bunch of resources that we've have at our disposal Welcome people if they want to write blogs contribute We can do that if you want to talk about a security topic. We would love to have you See if we have a slack channel an email and a bunch of other resources that that you can get involved with as Chris short brings it up and I love that you have dark mode enabled already. That's perfect system default Yeah, thank you for picking up on that. We love it So what's going on here on this site? Fancy stuff right supported open source communities cloud me Kubernetes Yeah, so we do office hours. We've done office hours every Every month we recently did one that was on ebpf So you can check out our office hours there We're trying to do once a month and Again, hey, we're we're trying to open them up to so there's office hours And we were looking to do something on twitch if you wanted to do something more security specific with stack rock so again, if you want to get more involved send us an email join us on slack and you can ping me I'm on the CNCS slack as well. So For now, it's it's a placeholder and we look to bring you more and more Information as things move forward because the open sourcing process is is a lot There's a lot of considerations involved in setting up an upstream project. So We'll be with you the whole way through it and Honestly, I'm really excited for it. I'm glad that we could do this and honestly do this so quickly. So Yeah, this was a fast turnaround given other acquisitions redhead has done Like I remember Ansible Tower took like a year and a half or so to open source like this was very quick Yeah, yeah, it was we hit the ground from day one. So It's it's really honestly great to see everybody Become so interested in security. I mean you're looking at kube.com to you right now and some of the tracks We have like one-to-one tracks talking about security. So it's It's it's an awesome time. I'm glad that people are are taking security and kubernetes more seriously Yeah, I just popped over to the community page here and I'll drop that link in chat Okay, and Yeah, we have some questions. We have kube. I mean obviously kubeliner already has And an upstream project Any idea what's going to be next? In terms of of say named projects that are going to come out of the stack rocks tooling Do we even know that at this point? For now, it's kubelinter There's some existing functionality that we wanted to add on to it. You can check that out in the github repo as well There's the the project roadmap. I know that It's it's a more it's a developer focused tool. I don't recommend anybody specifically who wants to get started with policies in their ci to specifically check it out it's Just a low Knowledge gap really easy to implement on the cli. So kubelinter is one stack rocks is going to be two I hope that there's more but Right now it's it's it's one at a time. It's they're they're pretty significant tasks So yeah the And by the way for those of you who are asking questions here. We see you and for that matter you ask a question In here we produced some kubelinter shirts Which think of the first ones that have been around we will be giving those away And just watch the chat for how to claim yours So we have a question here Magno picked up on The comment actually the discussion of a cncf discussion of falco That we're going to be contributing upstream patches to falco based on stack rocks's work Yeah stack rocks has always supported the falco project and As you saw robby specifically one of our engineers falco wants to move to graduating and You know, we just really supported with the project and we wanted to make it known robby actually just commented last night About our support and how we support it graduating. So Yeah, we're looking forward to to just you know continuing To to help that project in any way that we can because Especially with falco and runtime security and falco sidekick. They're doing some great work over there So it's awesome to see them move towards graduating and all the best of them and we hope to help them any way we can also the But I understand that there's a number of things where there's been Work done on on like existing projects by the stack rocks team that you know, you all have Due to acquisition a lot of other things that had not been able to get around to contributing To those projects that are not going to be going ahead. Yeah Yeah, it's that's uh I should have brought robby on because that's a more of a question for the engineering team. Yeah when you're Yeah, when you're trying to contribute these projects, there's There's a significant amount of back and forth to make sure that you do it in the proper way, right? Which is why you have these SIG governance and Why as part of the graduation to CNCF there has to be some sort of process for for contributing. So Yeah, it's uh, you know, we're currently in the process of working with falco to make sure that these things are done and done in the proper way and There there's been nothing but helpful in in bringing us on and and talking to us through the process. So Yeah, it's uh, let's just say with the with falco in the upstream stuff. There's there's more to come on that side Nice. I like the sound of that um, I A lot of questions. Let's see. Um Man, I'm never gonna try to pronounce this nick. Um, somebody wants to know um I Is there gonna be any opportunities for students? Um in the sac rocks community? Oh, yeah, of course. Um Listen, I I actually really like the the thought of opening the floor if we're doing office hours people come in talking about projects Even even if blogs something as simple as Um, you know, hey, I'm this is how I'm protecting my cute config files And I just use a password and I'm encrypting my cute config files or mounting it at a specific time And then the timer's up and it unmounds or you know, whatever it is some simple project You want to talk about it and you know, it's security focused. We love to have you write a blog I think it's awesome to have people have works that are published on a public forum Uh with community a following community guidelines obviously and then You know, we can use that as as student projects for leverage for, you know future employment And future, you know work in the open source project. I think it's awesome The if you want to uh to learn more you can join the stack rocks channel on slack the cncf slack It's an open channel. Uh, you can also email community at stack rocks.io And you can get learn more that way You mind if I put that in chat? Oh, yeah, I would love that Yeah, magnos got a ton of questions magnos, uh One of our good friends. He's hosting, uh It's the capture the flag from cube con security day, which they did an awesome job. So, oh, yeah, that was very cool I watched that that was awesome If you have the chance go back and watch that folks. I'll dig up the link for it the uh speaking of which actually, um Imagine you almost do Already do a lot of work with kubernetes security um and the cncf Tag security now Tags Uh, yeah, we I mean, there's a ton of stuff that they talk about the meetings are really well done and managed by by tabby and ian and uh Yeah, they're they're a great group and they're At the beginning to get more prominent I think the tag security is a good step forward in terms of getting plugged into a lot of these projects because Six security tended to just be you know slash sick to or slash six security to get them on to issues But there was really no necessarily process for following up So yeah, we we try to get tuned into that just so that we can also know what's coming upstream into the project To right like with psps and uh docker deprecation and things like that and uh, you know contribute where we can Okay, um, I want to actually pick up on an earlier question than the problems that we would answer um, which was um I somebody was you know watching Uh chris's whole demo and that sort of thing, but they already have employment on um core kubernetes And they were asking what tools work with core kubernetes and obviously those are going to be tools out of The community rather than tools out of open shift and red hat products um The kublinter obviously is the one that works today Um, do we have anything else? Do we have anything else that that we have planned enough to talk about it? um That will will work with core kubernetes Well, the stack rocks commercial product does work with core kubernetes Right and you can see some of the stuff on the stack rocks github. These are you know The things that are our commercial customers are using with other tools as you can imagine with a tool like this You know, it has to be part of the the pipeline and the you know, the tools that you're using In both your your dev ops environment. So pipelines chat ops systems, you know ticketing and others It also has to work with of course the security tools So there's a whole you know suite of security tools like security event monitoring logging You know things like that that it has to work with and so that that compatibility remains in fact You know part of what drova well most of what drove us as a commercial product Right was the tools that our particular customers were using And with with the open source community now We've we've got I think a better potential to to go in directions that maybe you know Our commercial customers aren't using right new tools and new ways of doing things You know, so some of the less popular cicp pipelines are emerging patterns around get ops and things that You know because they weren't in wide use among our commercial customer base But will be more widely used in the open source community. I think we've got a chance to to expand that that compatibility um You know the the red hat approach here the support for open shift doesn't mean that we're suddenly going to make it You know open shift only or that we're going to be you know doing that it means things like You know Single sign-on is going to be consolidated with with open shift for our enterprise customers to enjoy just some convenience And and assurance there that doesn't mean that we're going to suddenly take away You know some of these other other You know the other integrations because the the kubernetes community has remained pretty, you know unfragmented right the api Drives that whole community that level of compatibility and as chris mentioned, you know the stack rocks focus on leveraging that api Um really means that we can enjoy that that compatibility out there It also means that there's work to do when things like psps get deprecated, right? So our product has to keep up with that and as new uh new standards are emerging and are being proposed in in cncf Um, you know, there's an opportunity there for us to take advantage of those new things We're always thinking about how does this new kubernetes feature? How does a technology like service mesh for example Enable us to do better security, right? And that's one of the things we're thinking about down the road How do we get better security out of what is ostensibly uh an infrastructure and productivity convenience, um, but maybe we can leverage it for security So we're looking forward to for that part of it. Yep. And also how does that thing add risk? That's right It's not the first time where you know a new platform that everybody's racing for people think about security kind of as an afterthought It's happened with cloud and happened with virtualization Uh, I suppose it means that, you know, there'll there'll always be opportunities for security folks Um, because it gets it gets thought of, you know, second, but um, especially with the community focus here We've got an opportunity to get ahead of that problem and say hey, um, we can leverage this for better security, you know Without shifting the context too, which I think is big Yeah, it's tough line to walk I mean, I think stack rocks for the last, you know, three years of the commercial entity has proven that it is walkable Right that we can maybe make the security teams happy and the developer is happy at the same time We can allow security people to come in and say Instead of being the the the team in the room that says no We can't use this technology. It's too much of a risk now. They can come in and say, hey There's there's a way for us to to leverage this right to take advantage to be the You know, the enablers of that that business, um, rather than than just the the folks who say no Yeah, I don't think you really had a chance to get to it But there's a whole host of integrations right with other platforms. So yeah, one of the big thing is, you know People don't necessarily consider kubernetes specific security until after and they already have all these big contracts And so how do you tie this in so that people aren't moving through all these different pains? And so if it's If you didn't want to work with the stack rocks ui you could set up your alerts Chris there's there's a whole ton. I don't know. I'm completely blanking on some of them But like you know syslog all your different s i m integrations. So That's right, right. So when enterprises are selecting a product, right? I mean that and that's the you know, the market director is big organizations, right as a commercial product We needed to make sure this is going to work with the tools that they're using And in some cases that means bending some of the abstractions a little bit, right? So that it works with a tool like a splunk right or a sumo logic service, right? security and event monitoring about an incident that occurs We think about runtime security as something that is A great way to inform our efforts to improve the source code For for hardening against runtime attacks, right runtime is a place where we can learn a lesson And apply that lesson going forward rather than just something that needs to be, you know, just continually monitor But you know organizations have these processes built around monitoring investigation root cause You know, and that's something that we need to be in line with The the list of integrations of course leverages standards as well And that's we've been able to do some really awesome things like that by getting information out of this product And into other systems pretty easily through, you know, webhooks even syslog Um, I thought that protocol would have died a long time ago, but Here here. Here we are. It's 2021 sm2c and syslog Yeah Man, it's bringing me back. So syslog still it's the one of those standards and you know, there's more, right? There is a whole api where you can pull from this product as well Like any good modern application. It's api first. So there's actually a lot of possibilities For doing things there and again, we're looking forward to, you know, to what the community might You know might might propose for that. I'm looking forward to getting my hands into it Yeah, awesome I have to see say that seeing Our syslog and kubernetes really terrified me but the Fair enough I Let's just say in the the early aughts there were some major issues with our syslog That that allowed me to take down at top 100 website The um, yeah So Um, okay the okay, that's not really a question we can answer um, so New stack rocks community stuff um You've got blogs and things You're looking for guest bloggers in the security community Yeah, yeah, it's open uh open forum for for people if they want to write blogs obviously it's uh Community guidelines and needs to be looked over so recommend emailing or getting involved in the slack channel, you know Paying me if you were looking to talk we talk about a specific topic But yeah, so welcome to towards the community if you want to talk about anything security specific so Uh, and then obviously that's going to be the place for announcements moving forward as we open source stack rocks project So it's uh, and and honestly so happy that we get to keep the name Yeah, stack rocks and go open source. So yeah, hopefully uh those cubelenter shirts and the stack rock shirts aren't going to be the the last of them Hope not the um, I don't know think so. I mean the um Company names tend to become product the indoor project names Yeah, it's uh, I think it was just one of those lessons from elastic, right You open source your project and name it elastic and then amazon ticks it up then calls it elastic And there's a whole host of issues that come along with those that so yeah, it's just it's good to see learning experiences Yeah, it's why it's why most of the time when stuff. I'm not saying most of the time when stuff originates here at red hat We try to have a separate community name from the product name Um, so that uh, also it really helps our people right because We do have a whole support large support staff and when they get a call they want to know what the customer is talking about For sure So, um for Um So people just want to Here so people just want to talk about security topics to go to slack Yeah, if if you're just interested and you want to ask more questions, there's an open forum on the cncf slack channel Just stack rocks channel And yeah, feel free to drop questions in we'll answer what we can as Moving forward. There's a ton of people who work at stack rocks in that channel and It's the best way to get in touch with us If you want to learn more Yeah, no heckling Chris heckling the so More engineering topics don't mind me sliding into something else here um, one of the big one of the big so One of the topics a lot of people have been talking about lately in relation security is Secure supply chain Um Is there already Features in stack rocks for secure supply chain So there's definitely oversight of You know, where do my components my artifacts come from right? There isn't necessarily a restriction until a security team decides that they you know, they want to restrict that, right? So we we err on the side of flexibility like you want to pull that five-year-old image from docker hub We're just going to be very transparent about what's in there That you're you know, you think about you're taking that on as part of your supply chain You're taking responsibility for that And we're going to show you the you know the truth about about how it was built and and you know where it is There's there's a lot of that abandoned where out there. So No restrictions by default, but you know, certainly most of the commercial organizations that I speak with Are restricting that an attempt to control that supply chain. I mean solar winds has everybody, you know, absolutely You know on fire about this topic, right? Where are we getting this stuff from are we building, you know, known vulnerabilities into our our applications? So that's where to the where stack rocks, you know, the acs product here fits in with the larger picture Open shift, right that open shift platform has capabilities and registries like quay and image signing and other things that will provide security teams with more assurances about that um I gotta say I think like the problem with secure supply chain is actually It's actually easier in this case, right? You think about kubernetes and everything that gets built coming from source code You've kind of got that asset inventory, you know, so many of the the breaches that you see publicly or around Well, we you know, we have a maintenance process. We have a patching process, but we missed that one We forgot about it. It was like somebody left that door open And we didn't even know there was a door back there So I think that consolidating application strategies on a platform like kubernetes and open shift actually has that benefit that nothing goes Invisible right if we see we see if we see every pod we see every image that's in use and there's a little bit more You know control over the over the source and the supply of those things So without trying to break everybody's environment the product definitely has features there to control that but We're not there to to you know to dictate the terms a bit to these organizations That makes sense too kubernetes is so hard. I mean kubernetes when you first fire it up is pretty open by default, right? I mean, that's why clusters like open shift exists. So having that open by default great to get started Really poor for security Oh, I remember I remember when we flipped over to our back being compulsory as opposed to being an optional feature Oh, yeah And and and that was that was one of our first points where people refused to upgrade Wow Wow, yeah, that's well because because if they didn't if they didn't care or they thought they didn't care and They had a deployment process that simply didn't Check for permissions All of a sudden having to actually pay attention to permission. Yeah, I guess it is a burden at that point, but geez It must be a search engine allow me to find open kubernetes api endpoints on the internet, right? Somebody's got to have one Yeah, I bet rapid seven has a list somewhere. Yeah The I remember the list back when I used to work in postgres the list of of open postgres ports You know postgres is an enterprise database and and first rule of postgres security is you never leave the postgres port open to the internet Because a database port has to emphasize performance and functionality over security And and therefore default security rule is simply don't you know restrict who can access that port um I think we discovered What was it 10,000 open port instances off a web post in poland? Yep, because people just do stuff They they had a product That didn't differentiate between internet and internet And just deployed it As part of their their cloud Yeah, we see the same pattern repeated, you know ad infinitum right mongo db s3 buckets, you know now kube api endpoints and You know the kube api endpoints, uh You know becomes a problem when you when you discover a cve that allows an unauthenticated user to do certain things, right? And that was one of the big issues from from last year that we reported on and and you know sick security dealt with right so And then of course even when something is discovered and well known People leave old versions running forever. And so uh, you know I mean if you look at the top 20 exploits from 2020 right published by by nist, you know cyber security you see Three four-year-old exploits the same struts exploit that you know, then god equifax, right? That that exploit still exists in the wild shell shock, right? so You know these things these things don't get solved overnight just because somebody has a fixed published I I will tell you from having worked with Power systems as in power generation systems Um windows 95 exploits are still relevant Yeah the um So, oh, okay. Hey, we have uh GoPro wants to know You mentioned supply chain attacks the of thoughts on sigstore.dev Any plans on working with and integrating? Uh, chris, do you know about that project? I don't Yeah, I was gonna say I think it it correct me if i'm wrong uh, chris short, but it has to do with Basically cryptographically hashing Images all the way through the supply chain and then looking at runtime to verify that it's the correct hash and that nothing's changed over the process Uh, I think it's a really cool project project. I know red hats actually contributing to that with google. I think in in a couple cases, so Don't know what the plan is because i'm not that tied in with With the product and what they're looking at in the future, but I think it's Reasonable, I think it's a reasonable to assume probably in like a three-year roadmap just because I Think it's a great project that it will get tied in in some aspect into open shift. So All right, I hope it does I'm I'm just looking at my crystal ball right now. So don't take anything I say for Right anything about the future is yeah tbd There's I mean, I think is there's so many potential times like i'm friends with uh, uh, nisha kumar of the turn project Is really focused on bill of materials Yeah, um And and I know that we've got folks in red hat sec ops We're also very focused on bill of materials for the whole red hat toolchain, right? Um, which has always been a thing for us So There's a there's a talk qcon acorax. I think it was an acorax. Um, i'm forgetting his name I think it was john concella did about security nutrition labels for projects, which I thought was pretty interesting um Speaking of just, you know different implementations of hey, you have this project or this microservice and here's the security The impact just the nutrition label that comes with the project that's on github for everybody to see sort of all the requests that it needs and Projects can also interact with that and I thought it was it's pretty smart. Everybody recognizes nutrition labels You don't have to be security focused to look and say, oh this could be bad if I download it and run it, right? So There's a there's a lot of cool projects coming out of open source security right now So I'm interested to see it. Yeah, it contains 70 percent of the sec ops rda of unauthenticated rest requests the That that does sound like a cool thing. So we're we're almost at the end of our time here um So any any last thoughts on state of security on the new site new community? um anything else chris, I'll let you have the last word but uh in terms of New things just super excited that we got to get it out and super excited that red hat is Upstreaming this and opening it to the community to get involved. So excited for that again slack channel email ping us We're glad to have you on board. So chris If you need to distinguish between chris's here on this one. Oh, yes Uh, porter There you go. Here I am Uh, you know, I I I love the discussion here and I'm looking forward to more of it. I think um, you know What I really love about the the community is is all the ideas that come in I I love about stack rocks and as a as a you know background in security The part I actually like most about this and I hope to continue embraces this as well is that Security needs to work with the platform We're trying hard to preserve the value that you get with this the old things that we've talked about right restrictions and admission controllers and Signing and everything else needs to remember that we're adopting these containerized, you know Get ops and dev ops, you know driven process for a reason right that the applications Are there to you know to benefit us and and you know, we want to act in an agile way I never want to see security take away that hey, there's this exciting new component It's someone's pre-built got this thing that we can add in here to improve performance and deliver better features So I think sacros embraced that better than than anything else I've seen and and I want the community I hope to preserve that so i'm really looking forward to it cool awesome, so We'll have more office hours this week because it's coopcon week Um boosted a link in the chat for where you can find our schedule of those um And if you're here because you really care about security you care about stack rocks the obvious place to go to continue the discussion Is the new community which you can reach off of stack rocks dot i o You are also welcome to drop by the red hat slack chat for coopcon I uh On the cncf slack But do visit um the new uh stack rocks community um If you are a security geek Because that is there for you Thanks guys. Thank you all for joining. Thank you to the audience for participating. Really appreciate it next up at 1600 central european summertime we're going to be talking about Come on calendar cluster management So feel free to join us then we'll be around on the slacks and various channels here and there And until next time stay safe out there folks