 Hello and welcome everybody. Thank you for joining us today. My name is Andrew Sullivan. I'm a technical marketing manager with the Cloud Platforms Business Unit here at Red Hat. And as you might have guessed, I am not Chris Short. So for those of you who are familiar with, you're used to seeing Chris Short here in the chair, I am or Chris is having some technical difficulties today. I'm having difficulty speaking. So Chris will be rejoining us as soon as all of that gets sorted out. But I was able to, my schedule allowed me to step in and join here today for what is something that I'm really excited about. I see, well, I see you made a comment there about you didn't see this on the Twitch schedule. I didn't either, I didn't know about this until kind of the last minute. So I'm really excited to be here. So today we are joined. We're here for what is the first of the Stack Rocks community office hours being hosted on OpenShift.tv. So I know that the Stack Rock folks have been doing these for a while now on different platforms, but it's really exciting to have it being hosted here. So joining us to talk about where to host for today and I believe I'll let you handle the subject here, Connor but is Connor Gorman. So Connor, if you don't mind, please introduce yourself in today's show. Sure, awesome. Yeah, I'm Connor Gorman. I'm a senior principal engineer at Red Hat ACS, Advanced Cluster Security, formerly known as Stack Rocks. I've been at Stack Rocks and now ACS for really close to four years now, four years in August. So, worked on the product for a long time, really excited about all the progress we made and excited for the progress for the future. In this office hours, I really just wanted to introduce a brief overview of our product and what we're working on and also just answer any questions anyone has around Kubernetes security, cluster management, anything related to security in general. I always happen to answer any questions around that. And yeah, we'll go from there. Awesome, so, sorry, go ahead, Andrew. No, I was just going to remind our audience. So office hours means that we are here to answer your questions, whatever it is that's top of your mind, whatever it is, whatever questions that you may have, that's really what we're here to help answer. While we may not have all of the answers off the top of our heads, we're happy to take any of those that we can't answer. We'll find those and then we'll follow up on that to make sure that we can get them. So, don't hesitate to ask in chat, whatever platform you happen to be watching us on, whether it's Twitch or YouTube or any of the others. Feel free to ask those questions in chat. We will get those, it rebroadcast them across all of it and then we'll have that conversation. So, don't hesitate at all to ask questions. So, I'll kind of kick things off and I'm going to set you up for what I think is a softball, right? And that is ACS, Advanced Cluster Security, Stack Rocks. It's a new acquisition by Red Hatch, just a couple of months old now. I hope you are adjusting well to the Red Hat fire hose. We're really happy to have you here. But I think a lot of folks are still, they're still trying to understand Stack Rocks, right? They're trying to understand ACS. What does it do? How does it fit in? So, if you don't mind, can you kind of start off with that? Sure, yeah. So, you know, Stack Rocks and ACS focus on kind of like three main areas. I would say we focus on, and it's like overall dev life cycle, right? So you focus on builds, deploy, and then runtime, right? And so, you know, I'll show you some examples later, but as a build perspective, right? You're looking at images. You're looking at, you know, best practices within those images, whether or not it's, you know, having a maintainer in your Docker file or, you know, the vulnerabilities that exist and which ones are fixable, trying to give that information back to developers, right? And so we integrate, you know, heavily into CI systems and, you know, giving that feedback directly in a CI pipeline. You have deploy time, which is honestly really multifaceted. You have everything from build, right? Like the point of build is to go deploy something and then, and then, you know, so you have a, you know, you'll launch a deployment in Kubernetes and you have an image there. What, what vulnerabilities do you have in that image? And then also the context around that, right? Which is you have a deployment. It's exposed over a load balancer. Maybe it's running as privileged, right? And, and which thing should I prioritize first? Should I, should I look at something that has, you know, a critical vulnerability, it's on a load balancer, exposed to the internet and it's privileged. Let's go attack that one first, right? And we try to give you a prioritization of here's the thing you should go look at. Here's the critical stuff to go fix. Both from a configuration management side and from, you know, a vulnerability perspective. Yeah. And that context is that, that's both the, the really important and the really hard part, right? Of how do I know that this one is the most important of the important, right? If everything's a priority one, is anything really a priority one? So getting that right is the hard part. Yeah, exactly. And, and I think what we try to do is give you a view into, you know, a multi-cluster approach. So it's not, you don't, you don't run StackRox in just one cluster. You have kind of a central hub and you can connect a lot of your clusters and a lot of people use automation to deploy, you know, tons of small clusters. And so, you know, if a critical CVE comes up, how do you say, where is this in my infrastructure, right? And like, and I think the answer to that question is really important of being able to just type in CVE XYZ. Okay. These deployments, they belong to these teams, this cluster and namespace. Okay. Here's what I need to go track down. And then also from a deploy perspective is how do I stop stuff from coming into the cluster after that, right? So I always think about continuously trying to, and you could call it compliance or best practices, but it's, if I find 10 things I know I need to go fix, let's not add 11 and 12 and 13 to the list. Let's create an enforcement policy. Let's block it, have it go back to the developer who's trying to deploy that and say, hey, you can't deploy this. Here's the policy. Here's how you remediate it. I think also, you know, you can't just have a policy violation and not give any context around, here's actually how you go fix the thing. And also here's why we created this policy. I think developers are always curious about why you're doing something, why is this a rule, why is this CVE that bad, you know? So, you know, trying to have that context is really important. Yeah. So we have a question here from Walid. So hello, Connor. Wondering if you have SEC, RBAC, more visibility, like who is reading secrets, what service account is using a SEC in a visual way? So kind of, I think the reporting aspects as well as what type of visibility into objects are being used. Yeah. So expanding a little bit, in other words, admins have a list of bad practices when it comes to security controls around RBAC, SEC, network policy and others. Yeah, so we have the ability to basically look at a service account or a subject in the RBAC world and show you what permissions they end up having, right? So that's always been a challenge in Kubernetes. You have role bindings, you have roles, you know, you have service accounts, you have subjects which aren't even like real Kubernetes objects. They're just kind of reference things and then they get inferred. And what you wanna see is, you know, what access does Connor have in this cluster, right? And like what verbs and resources can he affect? And so that's something that we've tried to address as well. And we have, it's available in the UI. It's not a nice graph for anything like that, but you can see the verbs and everything there. And then also when you're creating a policy, you could say, okay, show me all the service accounts that have a cluster admin role or show me all the service accounts that have above this level of privilege. Like maybe it's not namespace scoped, something that's cluster scoped, for example. And so you could go look and highlight those as well. We currently don't ingest a lot of SEC data. So that's the challenge. We can create a lot of policies based on things that are related to SECs. So users and groups and things like that, a lot of security context, but not the SEC itself. Got it. So I'm gonna challenge your multitasking a little bit. So I think you said before we started that you've got a cluster, would it be possible to see some of that, what some of that looks like? Sure. And then maybe if you're able to kind of multitask a little bit, we do have another question this time from Adrian. Are you using OPA internally? And if not, could ACS integrate with OPA or are they mutually exclusive? Sure, so I'll start sharing my screen here. So we don't use OPA internally. We have our own policy engine that we use. Part of the reason for that, just some background context is that we stitch a lot of things together that made it a little bit challenging. We did take a look around images especially in terms of trying to figure out, for example, if you have a CDE with the CVSS score and it's fixable, you kind of have to stitch all of this data together. And so we have the multiple stages like I described, you have a deploy time policy that has, oh, this deployment comes from over here and this is privileged and this image is getting pulled in and it has ZCVEs. And of course, deployments can have multiple images. And so you really wanna drill down into this particular information and then get all these results out. I'll show you that in one second. And then for now I'll go into our back visibility. And so we have like a list of the user in groups, right? You can see that I have an admins, it's a cluster admin, of course. Joe at example.com, right? He can look inside the payments namespace, he can look at all verbs related to secrets, right? Or, but he doesn't have any cluster permissions which means that, you know, you can't access anything outside of payments. So this is actually an example of probably something pretty well-scoped. I'm not sure why he needs to look at payments so closely, for example, our secrets, for example, but these are some of the aspects of things that you can look at. It's always interesting too, to look at system namespaces or system service accounts and see what access they have. So of course, a system one will be able to look at everything, but oh cool. Kube proxy can pull events, look at end point slices and end points, nodes all seems pretty sane to me from what Kube proxy would need to do. And then, you know, do I go ahead? Can you, and while he asked us, so I'm gonna rephrase it slightly. So Willie, please let me know if I missed a mark here. Can you look at it rather than from the role or the role binding into what permissions they have rather from the other way around. So like, can I see what roles and role bindings have like the, you know, view verb on secrets? So I don't think you can do that today. I mean, I think you can just look up subjects and subject kinds. That's an interesting question to say like, okay, who can read my secrets in this namespace, right? Let me click through real quick, but I don't think you can necessarily look at it that way. No, so yeah, so there isn't the ability to look at a specific permission and break it down. I'm happy to file that though. That's a really interesting idea of being able to say like, who can give secrets in this particular namespace? I think that's like a really valuable thing. So yeah, instead of being kind of like show it in this view where you have a role and it will show you which rights you have. So that's an interesting point. I think there was another part of that question which I am now blanking on that he had mentioned. So there was visibility into like who is reading secrets? You know, that type of, so I think that's more along the audit lines. Yeah, so exactly. So I actually wanted to mention that because I just saw a demo of this today and it's coming soon to our product. So it's really exciting. But yeah, we're gonna be able to pull in the audit logs specifically on OpenShift clusters and be able to highlight who's reading or writing secrets in config maps and look at them, you know, even with people who might do impersonation or something like that, we can highlight that as an alert and alert it in our product in an upcoming release. So really excited about that. It's a really topical question, just at the right time. Let's see, so cool. So actually, if you don't mind, I can jump back to the question around. I think the question was around violations and OPA and why... Yeah, please do. And just because I don't know what it is and in case somebody else doesn't, I don't know what OPA is. Oh, cool. Yeah, no worries. Yeah. Awesome, yeah. So OPA is Open Policy Agent. It's recently was given to the CNCF as a project. And basically it uses a language called REGO and allows you to write policies. It's also the backing of OPA Gatekeeper which is specifically an admission controller for Kubernetes. So I think that I hear a lot, talked about it a lot. That's where it comes up most of the time, especially with reference to our product. And so I'll go into a example here of something that we do with our policy engine and something I think is really powerful which is kind of stitch all this context together. So one of the policies you can create in our product and I will zoom in a little bit is something like, okay, if there's a CDE with important severity and recently we've been orienting around severity in terms of CVEs or vulnerabilities because the severities are rated by the distribution themselves. So Red Hat looks at a CVE and says, does this affect rail seven, rail eight? Here's the severity for it. A lot of times it'll differ from the CVSS score. So the score that you get. So you'll see something that has a nine but it may not be impacted because we know it doesn't use that code path or that library is not loaded or it's not included. And so the severity could be a low or moderate. And so that's actually a much better gauge of whether or not you need to go fix it immediately and helps you prioritize by looking at the severity. So. That's interesting. So it's going back to the context around it's not just a blanket. Oh, this is there. It's rather, is it actually being used? Is it actually vulnerable? Yeah, yeah. So exactly. And so, and there's even varying levels of that between distributions. So, CVEs just a top level thing. Okay. Curl has a, has a vault, right? Almost every distribution is probably affected by that vault potentially in some way or it exists in their environment. Cause I think there's very little difference between curl and in Ubuntu and rel and on all of that. But, you know, it does matter in the context in which it's used. And so, for example, if we look at this CDE with important severity and I, you know, this visa processor is privileged. It probably doesn't need to be, right? You can see cool. We've satisfied this constraint that is privileged but we also satisfied all of these constraints for all of these CVEs. And so it'll break down which CVE, you know, the score, the severity, which component it existed and then also whether or not it was fixable. And so I think the fixable aspect is really important and kind of what I would encourage people to orient on which is sometimes you can't, sometimes there are CVEs that come out, they're brand new and they're not fixable. And there's not a lot you can do. You can, it's really good to have an understanding of visibility into them. But from a practical perspective for a developer, you know, how do you fix this besides removing it from your application? And that's not always super trivial. And I would imagine that could also be an indicator of, you know, hey, pay attention to whatever the, you know, compromise indicators are or whatever that happens to be for this pod, this application. Right, exactly. And so from a developer perspective, if there's a version of a package that you could upgrade to, you know, and for example, the difference between this version and this version is so minor that you could probably just upgrade to it immediately or rebuild, you know, your base image probably has a fix for it. And so if you just rebuild your Docker image, you know, you won't be vulnerable to this anymore. And so, and a lot of times these are, these are almost no-brainers. Like, hey, I should go fix this. Like it should be really easy. And so this is like the action ability that we always like to show. This image is very old, it's got a lot of volums. This deployment is pretty vulnerable. And so you kind of just break it down that way. And then, you know, one aspect of the lifecycle I didn't mention is that we do look at runtime data as well. So we're looking at process and network executions and I can just set the lifecycle here to runtime. Yep. And you can look at some of the runtime or policies that we have created. So you can look at whether or not like Netcat was executed. I think the shell spawned by Java applications is really interesting. Unless you're running Jenkins, Java shouldn't really be creating bash shells. Jenkins does this quite a bit. I think we've all experienced that. And, you know, the first time we ran our product on a cluster with Jenkins, we immediately found, oh yeah, this is a valid use case. And of course, we have the ability just to, you know, exclude these deployments because there are, you know, that's another aspect of policy management. There's always exclusions that are allowed, right? You could say, I don't want any privileged containers in my cluster, but if you run StackRocks, we have a component that has to run as privileged because we're collecting, you know, efficiently collecting network and process information. And so there's always a proper exclusions. Yeah, that's been a behind the scenes war that I have waged in every organization I've ever worked in of too many alerts is worse than no alerts because it all just becomes noise and you end up missing important things. And you assume, right? I say it's worse because will you assume, oh, the system will tell me about it. And it probably did and you ignored it as opposed to with no alerts, you're probably gonna go looking, like, oh, I should probably check on that. So we have a question here from Duane. And apologies if I am mispronouncing anybody's names as my children can attest I am terrible with names. So would ACS provide secrets management? And if yes, how would it compare to a tool like vaults? And then the second part of that is image scanning. How about image scanning and comparison to how Quay does image scanning? Sure. Yeah, so in terms of secret management, we don't do secret management. Well, you can utilize Kubernetes secrets or you can utilize vaults. StackRocks is totally cool with that. Those are great solutions, you know, and we haven't tried to get into that space. So, you know, there's no conflict there. I think in terms of image scanning, Quay and our scanner are based on the same kind of core, like we were based on Clare v2 back in the day. And now, you know, Quay and Clare moved to Clare v4. We've added a bunch of different things. We've added some capabilities around node scanning, some language vulnerability scanning and also just like general, general change that we made around Kubernetes volums, specifically, you know, one of the things we found was like, hey, we're a Kubernetes security company and, you know, we focus on Kubernetes security. We've got to be able to tell you when Kubernetes itself has volums, we have to be able to do it quickly. And so we curate some of our own data around that just so that we can deliver it to people quickly because that's, you know, an expectation. And so, you know, we have diverged a little bit there, but when it comes to, for example, REL-based images, our results should be very similar, if not the same as we're all, like there's a scanning certification that we've gone through with Red Hat. And so that helps ensure uniformity between at least scanning of recent REL images, which has been really valuable. Got it. So we're getting quite a few questions in here. So I'm gonna keep going down the list. So from Walid, can you do granular auditing and then open shift filter metadata and data before sending it to SIEM? I guess I would have to have a follow-up question. It's like, in which perspective from an auditing, you mean from like just pure audit logs, from a pure audit like perspective, we've started with reads and writes on secrets and reads and writes on config maps. But, you know, I think there's definitely space to expand that in terms of, you know, filtering or going through policies. We currently have a lot of capabilities around taking policies and vulnerability data and pushing them into SIEMs. And so that you can ingest them in that manner. And, you know, we have a lot of integrations for policies in terms of notifications, right? And for runtime data or network, you know, anomalous network activity, you can push that into SIEM as well. Got it. And Walid, please do post a follow-up if there's any clarification we can do. You can also follow up an email if you'd like. So you can always reach out to me, andrew.sullimanetredhat.com. Let's see, where was I? How can you integrate OPA into the pipeline? Yeah, so right now they're fairly separate in terms of what we would, what we support in terms of ACS. And so we don't have like a firm integration with OPA today. Okay, so effectively it's not, they can coexist though, right? Yeah, so I haven't personally tested this myself, so take it with a grain of salt, but I'm like, you could definitely have two validating web hooks or mutating web hooks alongside each other. They just run in sequential order. So you'll be able to run, you know, check certain policies against ACS and then check certain policies against OPA, for example. Okay, so I think that might be in a roundabout way the answer, right? Of effectively run them side by side with the two web hooks. Right, yeah. Is ACS only available now in an open shift context following the acquisition? Is there an integration also available with EKS? If yes, how can the service be consumed from Adrian? Yeah, so I am not the expert on the current support matrix. I will full disclosure. I think I can definitely get back to you on that and make sure I'm saying the right things. So that's probably what I'll follow up. We can follow up on. I, yeah, I don't know the current state of the support matrix. Okay. Yeah, I know, you know, of course being acquired by Red Hat means that open shift will become the primary focus, but whether or not the other aspects will be, you know, immediately deprecated or sunset, I don't know either. Let's see, just trying to catch up on chat here. Where did I go? I would like to only do, so from Willi, to only do OPA integration if I cannot write custom policies in ACS. Yeah, so you can write custom policies in ACS. We have, I can just jump to that real quick, actually. Sure. We have a lot of different criteria and we're always expanding it as well. And so if I just go to one of these and I'll clone it or something, we'll make it faster. Clone a policy, hit next. Like basically we have a Boolean builder that you can use and you can step through, for example, this is looking at a process name. You can do negations, you can do ends, you could add different conditions to different sections. Something that we've seen a lot actually is if you're running something like Istio, you're like, I have policies, don't apply them to Istio. If Istio has a volum, it's gonna light up every single container or deployment inside my infrastructure. So you can say and not, you know, container name Istio proxy, for example, or a sidecar. And so we have a lot of different contents here. Sorry, it's a little squished on my screen, but you can look at storage, different volume sources and destinations, different container configuration around environment variables, making sure that people, from an operations perspective, making sure people are setting limits and requests when appropriate, which I think can help avoid kind of like taking down nodes or impacting other services, looking at privileged container, you know, read-only root file system, which is probably my favorite way to reduce the tax surface of your deployments. If you look at Metasploit, everything hits slash temp, because it always assumed slash temp is writable. So that's not, you know, that's automatically just significantly more secure from people running scripts. You can make sure people have dropped or added specific capabilities or not added capabilities. So, you know, don't add capsis admin, please. You know, I know it might make your container work. It's probably not what you need, but, you know, there's a lot of different aspects here that you can use and we're continually adding more in terms of Kubernetes, you know, these are new Kubernetes access, you know, service accounts, RBAC permissions and events themselves. So you can look at port forwards and execs, see who's doing that, you know, block those if you so choose. And so you can, you know, kind of secure your cluster that way by default. Yeah, I think well lead is paying a compliment here. ACS custom policies is much easier than the OPA. More like styro, styro, yeah, commercial offering. So I also saw, well lead up above you asked, is it typically Red Hat's policy to open source our offerings? So yes, effectively we open source all of our products, projects at some point. Some of them take longer than others. So for example, when we acquired Quay, I think it took something like two years before we were able to fully open source Quay or Key if you happen to live in the UK or Australia. So yeah, generally our goal is to always open source things. It doesn't always happen immediately because it's not as simple as, you know, a Git commit. There's a lot of legal things and all kinds of other stuff that have to happen there, but Red Hat is, and I've been at Red Hat now for three years, Red Hat is really amazing about doing all of that stuff. So kind of keep your eye on, if that's something that's interesting to you, keep your eye on all the various news outlets and stuff. We always make a big announcement around it when we do it. Awesome, do you have any more questions? I can show a little bit of network visibility if people are interested. Nothing at the moment, you know, please don't hesitate to ask any questions that you happen to have for anybody who is watching the stream. But yeah, please go ahead. Sure, yeah. So I think one thing that I've always been interested in as even from an operations perspective is, you know, what are my containers doing and what are they talking to and what are the interactions? And then, you know, how do I go build network policies around that? And so we leverage network policies to really create, you know, almost the pod to pod firewall, the pod to pod segmentation, super important in environments that are multi-tenant, right, you know, you've seen some of this with like OpenShift SDN where you have like namespace, namespaces will be automatically isolated. And so I'll just jump directly to the StackRox namespace where we're running our stuff and we can take a look here. I'll try to zoom in to a right level here, but we can take a look at our services and say, okay, what are they talking to? And how would we build network policies around that? Right, as you can see, Central is our main backend. It's got a lot of external connections because these are all us reaching out, excuse me. These are all reaching out to registries. So we host some data in Cloudflare. Docker Hub is hosted on AWS. And so that's how we end up there. And so, you know, we can see that Central is reaching out there. And if we click in, yeah, it's highlighting these as anomalous. And we'll talk about that in one second. Well, you can see that we're talking to our scanner, which makes a lot of sense. I'm telling Central to go scan specific aspects or specific images. These two are not supposed to be marked as anomalous. They just showed up after the time period of when we were learning about this. The nice thing is, is that we want to make it really easy for people to just add them to what we call a baseline. And a baseline is the way a user avoids a lot of noise and instead just says, yes, this is what I would expect my application to do. And then you can lock that. And you can say, tell me when I start deviating from that. So I will try to just add all of these to the baseline. Go for it, right? Cool, no more anomalous flows. And you can go to the settings here and you can see everything that we're talking to. For example, here we're talking to the image registry, which is the internal OpenShift image registry. I would expect that DNS and the router also make total sense because I'm accessing the UI through the router and there's ingress here. And of course I have to do DNS lookups. So this little switch here will let me start alerting on this network to network activity. And so if I turn this on and then suddenly I were to try to access this from a different ingress point, we would see an alert in the violations page and we can go investigate that. And we can say, okay, why is pod X talking to central? And I always say there's three reasons why that is. It's either my central is misconfigured. I'm like something else is misconfigured and trying to talk to me or I'm under attack. Like there's those three reasons and all of them are good reasons to go look at it and say like something's not working as it's supposed to. And you kind of can go dig in from there. So I'm gonna, as for anybody who watches my show regularly over my live stream, you know, I'm gonna play the role that I was born to play which is dumb guy, right? So a couple of things that are interesting or I'm curious about here. So baselines are set and these are effectively network policy rules, right? They're set at the namespace level. So any pods and please correct me at any point here. That's what I'm hoping for. So any pods that are deployed into that namespace automatically inherit these roles, right? You don't have to do anything if the horizontal pod auto scaler takes effect or VPA takes effect, right? Anything like that. Yeah. So the pods are just selected by labels, right? And namespace select there. So actually what we can do is we can look at the network policy that applies to central, right? In the UI and you can see that the, this part is the most important part, right? So central is exposed over the internet. Typically it's the one thing that we expose and we only answer on 8443. And so we wanna make sure there's no traffic coming to central that's not on 8443. And then this pod selector tells you that only central should have this rule, right? So you set network policies and then you can scope them based on this pod selector. So each of... I don't know if you froze or if I froze, but one of us froze. I think it might be Connor because I see myself still talking over here in Twitch. So I will shoot him a message real quick for anybody who's watching and see if we can get him reconnected. But he froze in a great position. Any time I freeze like that, it ends up with me being in a completely, non-graceful, horrible position while he committed a violation. His network policy booted him off. That's what it was. It seems I've heard a number of people having internet issues. I'm not saying that's what's happening with Connor right now, but it seems like there's been a lot of internet issues lately. I don't know what's going on with that. Knock on wood. I've been very fortunate to have a stable internet connection the last few months, but Chris Short and his internet provider has been, let's just say, a little suspect. Never a dull moment when it comes to trying to get reliable internet. I don't know what it is with the US and our internet providers. There was somebody else on our team that was having issues the other day, too. Maybe the, I would say, I guess we're all working from home still. If we weren't working from home, I'd say maybe it was like the company denied access to YouTube, like, oh, you've been on YouTube for the last 45 minutes. You're not working hard enough. We're gonna deny it. So we'll give him a couple of minutes to attempt to reconnect. If you have any questions, and while he did, I see that your question in here about build, deploy, run stages, if he's not able to reconnect or for whatever reason, I'll be sure to collect all of those questions and all that. We'll be sure to get them over to Connor. And then when the next stream happens, we'll just follow up and we'll be sure to cover those. I'll also follow up with them about whether or not they post those or anything. Like some of us will post a blog post to help answer questions, stuff like that. So we'll keep an eye on all that. Don't worry. We'll get all of that stuff answered. So don't be afraid to ask questions if you have them and we'll still get it fixed. So I think he's still trying to reconnect. That's what I'm getting secondhand at the moment. So Dewan, I agree with your sentiment there, looking forward to future sessions. It's funny as a host of my own show as somebody who, you know, I have a lot of things going on. I've started to treat the live streams kind of like I did podcasts before. It's something that I tend to keep up while I'm doing things and listen to and learn kind of through osmosis. I find that particularly for topics and areas that I am interested in, it provides a huge amount of just background knowledge that I can seem to inadvertently pick up, if you will. So this is one that I will be adding to my list along with Christian Hernandez, who was on just before this, the Get Ops Guide to the Galaxy. That's another one that I've learned a tremendous amount about. But security is one of those things. It's 2021, right? You can't not be cognizant of security and keep up with it. So, oh, so I'm hearing that Connor has completely lost all internet. So I think, Bobby, if you're, so Bobby is our producer today. So I think that what we'll probably do is go ahead and end the stream a little bit early. I will stay on the chat. So you are welcome to continue to send us questions through the chat. We'll follow up with all of those questions. We'll make sure that those get answered and ensure that we can keep going next week. Or I'm sorry, we'll keep going next month, which will be on August 19th, is the next office hours with the Stack Rocks folks. So again, thank you so much everybody for joining today. Really appreciate you staying with us despite the technical difficulties. It is what it is. But we will follow up with all of those questions next month when you happen to get those. Andre, where can you get a Red Hat? So we do have a cool stuff store, which you can just search, whatever your favorite search engine is, search for Red Hat Cool Stuff Store. You can see all of the Red Hat brand and stuff that's there. Unfortunately, we don't actually sell. We can't, for whatever reason, they don't allow folks to get the Red Hats. Like you see the one that I have back here, they give those to employees when we go through the new hire orientation. I get that question quite a bit. Sometimes your account team, you can reach out to your account team. I think they can get access to like plastic ones. They're not the same as these, which are like felt and all of that. But that is one way to do it. So all right, so thank you very much everybody. Have a great rest of your day, have a great rest of your week. And as Chris Short says, stay safe out there.