 Good morning. Good afternoon. Good evening. Welcome to another episode of the Stack Rocks office hours This is episode three and I'm here with Mendar de Wachtar to talk about Kubernetes network policies. I'm Chris Short your host with the most here on Redhead live streaming Mendar introduce yourself to the audience. It's your first time on the channel. So, you know, feel free divulge Thanks Chris for the short introduction. Yeah, hi I'm Mendar. I work with the Red Hat Advanced Cluster Security team. I joined Red Hat via the acquisition of Stack Rocks And I've been with Stack Rocks for just over two years and contributing to almost all the components of Stack Rocks Network segmentation, policy management, risk computation And outside my work. I enjoy being active trail running Cycling, kayaking. So if you are in the Bay Area and you know want to join in with me, hit me up Nice Things I used to be able to do So Kubernetes network policies There's a lot to them, right? But You're gonna break it down for us. So, how do you want to do this? cool so what I'm gonna do is share my screen and Kind of walk through Short and sweet demo not too complex Basically, it will take us through how to write network policies and what are some things to Look for when you're writing and enforcing network policies. All right So first of all, what are these, you know, what is a Kubernetes network policy, right? So In the simplistic terms, it's basically a means of controlling inbound and outbound traffic You know from the parts perspective, right to other parts are to the internet, right? and This is achieved via Something called as labels and selectors and widely used by various Kubernetes resources, right? Such as services as well so Kubernetes network policies and Kubernetes like the bugs are very like They're like the the network policies are like the guiding angels wherever whatever is the label, you know The network and if the network policy kind of sees it Satisfying it it will just you know stick to it. So that is one very crucial piece that is also important in You know identifying. How are you going to segment the applications, right? So what I'll do now is basically jump into, you know demo So basically let's create a namespace so that I can You know show whatever I yeah, yeah, so by default No network policies are You know enforced, right? I mean there are some CNI plugins are managed Kubernetes services, which like Deploy or claim to deploy, you know default network policies, but those are essentially Allowing all the inbound and outbound traffic, right? So basically it's Doing it's not enforcing or it's not, you know limiting any traffic, right? so it's as as it's its behavior is as there is no network policy, right and Keep the Kubernetes network policies being namespaced Has actually a huge advantage Although there are like some limitations, but it also has a huge advantage When we are thinking like Kubernetes has been a game changer in like how we like deploy and maintain applications Right or even to certain extent how we write applications, right? Everything is very application centric, right? and the basic principle being, you know You know the applications or the pods need like serve the purpose and you know disappear, right and With this namespaced kind of environment, you know multiple teams, you know, you know having these, you know Different namespace working in their own namespaces kind of allows you Kind of provides this natural way of segmentation and that is something, you know One needs to keep in mind When writing Kubernetes network policies and how you can take advantage of Network policies being namespaced, right? We will talk about some limitations and how we can, you know, overcome them later in the during the demo, but you know For now, let's get started So what I'm gonna do is I'm gonna Create a very You know simple You know Environment, you know mocking there's like a database. There's a middle layer or the service layer And there is a front end, you know the typical Okay, okay, so we are running into problem What is the DB supposed to represent? Okay, so we were missing in this. Okay. Got it. All right So So we have our DB. I mean it's essentially an engine X and that You know, which for demo purposes, I'm you know treating it as a DB then let's say we have a catalog service. Let's say, you know, this is an application which is Serving Which is basically serving Okay, so the issue was we did not create it in the namespace All right, all right. So, okay, let's get to what we have Interesting, okay, so there is the syntax error here So what I ended up creating me like a band name. Yes the first rule, right All right, so let's So let's create The service called catalog, which is basically, you know acting something like, you know, providing a catalog of products And so what we have is now we have two pods, you know One is behaving as a database, right? It's an engine Excel pine and one is behaving as catalog, right? So right now There is no network policy enforced in this particular namespace, right? so if I go into If I exit into one of the pods namespace Yes, that's correct. There we go. And let's say we try to hit, you know Google.com or something like that You know, I'm able to reach out. I'm able to reach out to the internet I'm, you know, I should be able to reach out to the other You know pods however right now I've not exposed any other pod You know as service like so what I'll do is I will expose db On port 80. Okay, and of course we are Okay So let's get all the pods again However, let's also figure out what, you know, let's look at the IP addresses the plus IP addresses that are associated with them and as well as let's look at the IP address and As well as let's look at, you know, what are the services that we have now? All right. So if I go back Into catalog And try to Get db. I should be able to reach to it. Okay So basically this what it's demonstrating is I deployed my applications, right without enforcing Kubernetes network policies, right and It's not controlling any traffic. It's open to the entire internet and You know communicating Open to, you know, any kind of intrusion Think unwanted things, right so There are two approaches to this when you're writing Kubernetes policies, right? You can start off by Having a deny all policy in place which which means basically deny all the Inbound and outbound traffic, right when you're deploying a new application Let's say in a test environment, you know, like It's not going to be used immediately, right? And what do you want to understand is, okay, you want to See how your application is, you know, kind of reacting to that deny all policy, right? How is it failing, you know where all it's trying to reach and another good thing to Accomplish this is to have good logging, right, right? Whether if it is failing if you know silent logging or whether it's crashing and things like that, right but The other side of the coin is writing Kubernetes network policies can be a daunting task and I agree to it, you know Many a times, you know developers You know kind of shed the responsibility to the administrators And you know there is there could be a possibility that there's no proper check between you know how the applications are moving forward, you know The other approach is like, you know put it in a test bed, you know with allow all and observe how the application is behaving, you know for let's say A window, you know where all the application is trying to reach. So this is going to be your baseline, right? Right and identify if that baseline is even something that you anticipated or even something that you expected Yeah, right. Yeah, there could totally be something wrong with the image. Maybe reaching out and grab a package kind of thing. Anything Correct. Exactly. And then kind of reverse engineer, you know kind of scope it down by putting in place, you know some network policies, you know And things like that. So for example, what I'm going to do now is I have, okay, let me first show I have deny all policy here. Okay, pretty simple. Yeah, pretty simple. It's selecting all the pods in the namespace demo And not allowing any traffic, right. So another thing, another point I should be touching on is network policies are basically like based on the rules of allow list, you know what must be allowed, right You cannot have rules, such as, you know, block these block only XYZ connections and allow everything else. You need to be explicit on what you are going to allow what you want to be allowed, right So since there are no rules here essentially selling like, you know, allow, you know, like we don't have any rules. So, you know, kind of block everything So what I'm going to do is take that policy and apply it to be angry It's going to rebel. Yes, I'm going to lose my I'm going to lose my PRP my customer base when they're trying to shop from my wonderful catalog. Yes, so catalog has a very beautiful index file Correct. So let's go back And try to hit Google if I did everything right, we should expect this to time out. Right. Oh, yeah, about it. Right. We can also try to reach out to the other pod And it should be all right. Cool. So right now we have like a completely isolated name space anything any new deployment or any existing deployment or pod in this name space cannot have an inbound at an odd bond connection to anything else. Right. So this is like, you know, in ideal world, you know, you would start here, you know, you know how your application is supposed to behave. So you start from the most restrictive network policy and then kind of move outwards right so as I already Okay, so exposed the DB service, you know, and I want my, you know, catalog to basically query the DB and, you know, like get some records out of it. So basically what now I need to do is I can now ingress on DB like, you know, from catalog, right, so that I can explicitly allow those two exactly exactly so that I can fulfill those queries, you know, so let's try to do that. So I have prebuilt this YAML file writing. YAMLs are kind of sensitive. I can understand a pain, you know, like even an indentation could make a huge difference. Don't try the tool for that. I feel like. I would actually want to touch upon a tool that I came across and I've been using it, which kind of elevate some pains of, you know, writing network policies, but yeah, we'll get to it. Okay, cool. So let's look at this, what this policy is informing, right, so it's, it's, and it will be enforced in the namespace demo. And on the pods, which have label app is equals to DB, right. And it's an ingress policy, right, telling that, okay, allow all the ingress from the pods, which are labeled app is equals to catalog. And this is the scenario we want to support right now, right. So let's just go ahead and apply that policy. All right. So that's the DB policy. All right, so let's see what all policies we have now in this particular namespace demo. All right. So as you can see, there are like two network policies, right. One is denying all the traffic. One is allowing a, you know, traffic to the pod DB, right. So one would question like, you know, how, you know, what is an effective network policy like what should happen when I have multiple network policies, right. So one thing is out of question like I created both these policies scope to this namespace for this namespace demo, right. So the namespace policies, the effective namespace policies basically the disjunction of all the rules. So basically, if I have policy saying, okay, don't allow, like, do not allow any traffic ingress traffic. And I have, and if I have another policy saying, okay, allow ingress traffic. So it's like a true and a false right disjunction. You're going to, what's going to happen is the effective network policies going to allow ingress, you know, for that particular part. So that's how network policies work. And how it plays, how it, how it is important is like, one needs to pay attention on how you're right writing network policies, like keep it simple. You know, don't write a network policy which is trying to address everything, you know, like having 100 lines of rule 100 rules in it. Don't make it too complex because complexity leads to mistakes. Network policies being, you know, kind of a challenge in the first place. If something breaks, it's going to be, you know, difficult to identify, you know, how it's, you know, what rule, you know, what rule is breaking, you know, things like that. So have network policies scoped to the functionality, like what it's supposed to do, you know, if it is supposed to work on a pod, like let's say in this case, a DB pod, you know, scope it down to that deployment that pod, you know, is it supposed to allow ingress traffic, ingress traffic, and have those things, you know, have this segmented out so that, you know, you can revoke, like take out some network policies if something breaks and, you know, work your way through debugging. Right. So the first, you know, one of the important rule is, you know, try to keep it simple. Right. So I have an ingress policy. So does that mean let's try to, you know, reach out to DB. Okay, let's see if it's going to work. Right. It's not. Okay, let's, let's pick up the IP address and, you know, try to get to it. So I have an ingress policy on DB, but somehow I'm not able to reach it via, you know, catalog, you know, from catalog. And the answer is you have umbrella network policy blocking connection for all the other, you know, pods, you know. So now what I have to do is explicitly add a network policy to allow egress from catalog. Right. So that, so when you're writing network policies, it's almost like you define the behavior on both the ends. You have an ingress policy on a pod. You kind of have to have like, you know, a egress policy, a complimentary egress policy on the other end with, you know, which, which you want to communicate with this. So it's two way communication. So yes, exactly. And the reason why is, I started off with the most, you know, most restrictive policy. Right. If I remove that restriction, right, deny all I can reach to DB from catalog and you can, we can walk through that as well. Right. But since I'm starting with the most restrictive policy and I'm, you know, opening one door at a time, I know what I'm doing. I know what I'm opening up. Right. You know, through these explicit rules in the network policies, right. I have this network policy for catalog. Again, it's saying, you know, allow all the, you know, allow the egress from catalog to the pods having label app is equals to DB. Right. The port numbers. 53. That's a very good observation there. Okay. Thank you. The writing ingress policies has been like it's traditionally kind of straightforward. But when it comes to egress policies, it becomes slightly challenging. Because to, for one reason being, you may not like one may not know how the application is exactly behaving like what does it take for the application to work properly. Where does it need to reach out? Does it need to reach out to, you know, GKE bucket to get some, you know, data for at startup time. But the most primary thing is most likely it will, you know, it has to reach, it has to be able to reach to DNS server. Right. To be able to resolve, you know, what, you know, the pods and external endpoints as well. Correct. Right. So if I do not have this rule, right, basically, if I try to reach the pod, you know, using like the name, right, it's going to fail. Right. Because I cannot reach to the DNS. And that's the most important note to make, right, when you're writing an egress policy, make sure you can reach to the DNS server, right, whether it be cube DNS or other DNS servers that you're used, make sure you're not blocking that. Right. Now there are caveats of this rule basically it's allowing, you know, traffic to all the pods on port 53. You can scope it down. You know, by labeling the cube system namespace. And, you know, like, kind of making the rule translating the rule to, you know, only reach out to cube DNS in, you know, cube system namespace. But for now, I'll just leave it as is. And move ahead. So let's apply that. And now we have three policies. We have an inverse policy on DB. We have an egress policy and catalog. Let's go back and see if we can reach out to. Yes. So we could reach out to the DB pod. Right. And we could reach out to the DB pod, not using the IP address because we have not blocked the path to the DNS. Right. So, this is, you know, this is like a very simple kind of demo I had, I have like double of more network policies here. I would specifically like to, you know, like, maybe show another one. As I said, you know, Yamal can be confusing. This is another form of More than one way to Yamala cat. Yeah. Yes. Right. So, So it's, I came across like a very, there's a very good meme out there, which is like, oh, there's like a Kubernetes which like a cat is very cute. Right. It says like, oh, you said like just Yamal would be sufficient. Right. But it's not the case. So both are essentially denying, you know, the traffic both ways on all the parts in this namespace demo. Right. But, you know, like there are different ways how it is written. So, you know, knowing like testing out the network policies is always, you know, critical. What you're writing, you know, the Yamal's, it's very important like you test out, you know, how the, the Yamal that you have written, you know, ends up being right. So yeah, I mean, this was the short and sweet demo. I had Yeah, and let's, I mean, this is an office hour. I believe. Yeah. Yeah, if you have questions, feel free to ask them. In your example, the You open port 53, but I feel like there's a better way to do that. Right. Like I would just open up port 53 to Cube DNS, Cube system to the, you know, API on port 80 or 443 depending upon the situation. I mean, how else can you like make that rule better, tighter kind of thing. That's, that's a good question. So let's open up that YAML. Right. So there are some prerequisites to do that right since network policies are tied to labels and labels on, you know, the parts. Generally, you need to make sure that, you know, if you want to scope it to something, make sure that that particular part has appropriate labels, right. Generally uses, you know, create namespaces and, you know, do not label them. People folks like label parts, you know, deployments and other things. Most likely they'll expose it through, you know, services like load balancer and things like that. But namespaces, right. So then you also got to like label the namespace, right. So let's let's actually try to do that. Let's see if I can actually do that without. Okay, so we have cube system. Okay, so I'm going to list people in the cube system, right. So we have the cube system sting right there. Let's describe cube system and see if it got anything. Nope. So we have this label namespace metadata stack rocks IO cube system. So I have stack rocks, the advanced cluster security instance running in this particular Kubernetes cluster which applied the label, you know, we do that. But otherwise you wouldn't see this label. So let's pick that label and kind of work our way, how we can scope down the DNS rule. Right. All right, so what I want to tell it is namespace. Okay, so scope it down. Right. So I want to scope it down. Match the label. Right namespace is equals to so and so. Right. So now what, so now we have scope it down slightly. Right. So what it's telling what this network policies informing is allow egress traffic to put 53 for all the pods to all the pods in namespace, you know, having gotten this label. All right. So it's still like, okay, you know, you can still reach out to all the pods in your DNS namespace. Right. So we might need to scope it down further. Right. So let's say, let's describe, you know, what your DNS looks like. All right. Okay. So huge idea. Yeah. So, there's a label here, which we can likely use, you know, gets up as equals cube DNS. Now, I want to also talk about, you know, labeling, you know, what, what, what are some basic rules or tips that one should, you know, be aware of when you want to segment the network policies or basically your applications. All right, I'm going to cut it again. Just so that we have it on the screen. All right. So what we have now is we have a network policy, you know, scoped down to parts having QD gets up is equals to cube DNS label on the, sorry, in namespace having that particular, you know, label, right. But the caveat to this is, although I've scoped down my network policy, and if someone is going to, you know, add a pod with the exact same label is going to start allowing egress traffic to that label as well. Right. That part as well. Right. So, there are two parts to this right writing network policies and forcing network policies and how you write those network policies but the other part is enforcing who can write a network policies and who can label resources in your environment. Otherwise, you know, anyone having you know those permissions to introduce new network policies or introduce new or update the parts with new labels can basically go around the wall that you're trying to create. Right. And there are a couple of ways to kind of achieve that enforcement you can have an admission controller in place that kind of restricts, you know, creation of, you know, like a patient of those resources are like creation of network policies. Like, you know, or you can also use like Kubernetes RBAC rules to basically kind of scope down, you know, who can do what right remember the principle of least privilege, the way you're going to achieve security is by adhering to that principle. Right. For example, if I had these network policies in place, right. And then if I let me just show allow all if I go ahead if someone is able to apply this policy, all my effort is waste. Right. Right. Because it's going to allow all inbound and outbound traffic, you know, to this particular names. Right. So, so, so they're like, you know, so that that's another important thing, you know, how you are going to compliment the network security through network policies is kind of having some kind of enforcement and adhering to the principle of least privileges, you know, so that people cannot go around that while you're trying to create. Yeah, don't hit the all the play all. Question and chat here, how can we make what I mean, what is the right, you know, network policy and to eat the, you know, make that accessible to the world that catalog pod. So, and I know that involves ingresses and RBAC and all that fun stuff. But is there a network policy for that. There. Unfortunately, no, there. No, it's because network policies are something, you know, application of it like they're meant to be application of it they're meant to be focused on, you know, application, right, what works in one environment but let's say you have Cassandra and things like that and, you know, like you what works for that particular environment may not work for other environment. But there are these, you know, basic, there are these basic points, right, what to look at right, let me actually, you know, go to that right this slide. Now this is not an exhaustive list. I've just tried my best to in a list couple of things which I feel are important to look at when you're writing network policies right. So first of all, you don't want to block reaching out to like, you know, the API server, right DNS, like the DNS servers, you know, that your application is going to depend on the, you know, reports that you want open so that if it is serving, serving, you know, like workloads on the internet, you know, you want to keep them open, right. If you have like exposed it behind a load balancer, maybe you want, you know, like, most likely you will want to have these health and health check in points open so that you can know, you know, whether your services, you know, your apps are healthy things like that. So there are like some, you know, basic things that one can start at and like work their way towards it. And like, again, reiterating, you know, like one can deploy the application in a test page, like observe how it's behaving, you know, for a certain time window and identify, you know, you know, whether it's meeting the expectation, right, and kind of reversing, like, start your way, you know, backwards, like start swapping it down. So definitely I mean, testing network policies is a crucial thing you do not want to break applications in production. Yeah. Yeah. Don't start testing things on prod. Right. But, but I also want to, you know, highlight one thing here like network policies, you know, like the declarative nature of Kubernetes and how you write applications or how you kind of deal with the resources in Kubernetes. I think it's in a way kind of pushing developers to, you know, kind of start moving the security from administrator to the application development, like basically those who are, you know, like developing application know the architecture of that application and how that app is supposed to behave, you know, the best, right. So, you know, it basically shifts enforcing security, you know, in the early phases of applications lifecycle, right, you know, it very well start in, you know, during the development of the application as well, right. So that's, I see it as an advantage. I see Kubernetes network policies and the nature of it being the declarative nature of it being an advantage, you know, to, you know, allow anyone like to enable the developers to kind of, you know, take that responsibility shoulder that responsibility to enforce security early on. So, somebody's asking how to do this with a route, like, you know, and of course, I'm going to link to documentation for that. So, let me just do that real quick. Yeah, so routes and kubernetes and open shift land are like ingresses and kubernetes land, they actually predate ingress. So this is something that bread had had to create to satisfy customer need when open shift was launched. So route specific security annotations and things like that are all documented on this page I feel like, and locking things down there is as easy with a admission policy so make sure that, you know, the ingress is good to go it's not opening things that shouldn't have open. And, you know, you can do that with a number of, you know, different. And, I mean, address types. Yeah. Yeah, they're like, you know, like, not everything is green with a network policies like, there are some pain points, right, like network policies are namespace namespace. Right. Scalability, right, is one of the challenge right you, for example, you know, standard DNS like allow egress traffic to DNS is something probably would be natural to throughout the organization, right. And teams deploying their applications in different namespaces, you know, might most likely, you know, want to have that template, right. So, there are, you know, like each, there are these CNI plugins and different managed Kubernetes services have, you know, different choice of CNI plugins. But these CNI plug CNI plugins have something called as like global network policies or like cluster level. You know, that kind of addresses the concern of scalability, right. Let's say if someone wants a workflow such as, you know, when any application that is deployed, must, you know, have, must allow egress to, you know, the DNS servers of that organization, things like that, right. So, these CNI plugins kind of enable it. And the Kubernetes network policies work in work hand in hand with like these network CNI plugin, the CNI specific network policies, right, so it's a complimentary, you know, feature. And most CNI plugins, you know, like, have, you know, things like visibility as well, right, like, you have deployed network policy, what next, should you sit back, right, that's, that's some, that's something always get asked, right, like how do you, how do I, you know, kind of observe the environment and how do I kind of adapt and how do I update my network policies. For example, like Celium has a very awesome, you know, like network observability, I'm not sure whether it's like a paid thing or not, but they have like some logs, network policy logs, which basically have like custom metadata telling okay, which network policy allowed or denied a connection from what part to what part, you know, things like that. I believe, you know, because, you know, there's EBPF and EBPF has been like, you'll see it being used in more and more places because, you know, the enriched data that you can get using that has been advantageous I think and the KEE data, data plane V2 has that feature as well. Celium has Calico also introduced that so Kubernetes network policies, limit the limitations, you know, look at, you know, CNI plugins, their network policies, you know, to kind of reduce the repetitive work of let's say CI CD pipeline, you know, things like that and observe observability. Right. So that's another important aspect to that. Very good point. I just linked in chat folks to the last episode where we talked about EBPF and implementing security and monitoring around Kubernetes with it. So, feel free to check that out. You can always find us at our web page, which is just simple link here live streaming. So, yeah, no other questions from the audience. I feel like Naveen, if I haven't answered your question, please let me know. And I'll ask, Mandar, but he was asking, you know, how do I get things out of the cluster basically have access to things. If a connectivity failure occurred like between, I guess, I think he I'm thinking he means between nodes. But how do you like diagnose if there is a fail connectivity failure. Yeah, like, he wants to know what's the source IP. So, so I'm confused by the question. So, all right, I'm trying to answer it well can be confused. Let me think of like, let me put out some couple of points. So is, can you access the, you know, the audit logs, the, you know, the Kubernetes API server maintains a log of all the, you know, requests that are coming to it, right. And I mean, essentially, when you, when I'm running a cubicle, you know, create namespace or get part it's essentially you know, arrest fall to the API server right and everything gets logged in there. Managed Kubernetes services, most, if I'm not wrong, most likely have the feature the logging feature turned on by default. So that's like one good starting point. Network policies are not going to deny are not going to block, you know, any communication between the pods and the node that the part is residing on. Right. So, if you can get on to the node, you know, you can, you know, run cubicle. If you're having admin privileges, you can keep total and kind of diagnose get the application logs and things like that. So I've got a question in here does stack rocks or now advanced cluster security help automate the management of these network policies rather than having to manually create them. That's a good question. And I would love to show stack rocks or ACS. Let me share my screen. Awesome. All right. Let me know if you can see the advanced cluster security. Okay, cool. So, one of the most, you know, I talked about a feature of stack rocks is a network observability network segmentation. And as you can see here, I'm not sure if you can see where I'm hovering, but basically top left. There are like three kinds of views active allowed and all right. So the active view is basically showing all the connections that are active right now, you know, so that's like a good way of, you know, of observing like you know how my applications are connecting and this is a test. Basically, I'm testing out, you know, how my application is communicating, you know, this is the view we provide details about you know what port and whether it's an egress connection the protocol and things like that. We also added support for a kind of scoping or making it explicit to which side or your application is trying to reach out to, you know, outside your cluster. So this is about active connections. So coming back to that question. Right. So, a loud view kind of provides that the space of how your applications or what all kind of connections your application can have. Right. As you can see like, you know, there are different. Let me zoom in. So these boxes or the squares are namespaces and these, you know, circles or dots are your cards and deployments. And each of them is having like a different legend. Right. Right. So basically, as you can see, if I hover over DB. If if you go back like I had a inverse policy in place for DB it and it would only allow connections from catalog. And you can see right cannot reach out to the external world you cannot see that arrow right. So same thing like, you know, like, you know, other part I think this one this was the one which I created. Now, you can go to network policy simulator. Let me let me filter down first so that it's okay. So we have this demo cluster and the associated namespaces. What you can you'll see multiple options here and what you can do with these is first view what are the active yamls. Right. So these are the policies that I applied to the namespace demo. Right. So I can see what are my, you know, network policies in this particular namespace. I can edit those network policies and upload them here and see how it is, you know, taking effect. You know how it's changing. Right. So there are ways to basically like upload network policy. Right. Let me see if I can navigate to the folder. I believe in you. Allow all I believe we had not applied. We did not apply that but all of a sudden your DB can talk to the API server. That seems crazy. Right. So this is another way to, you know, make sure like how your network policies behaving and whether it's, you know, kind of meeting the expectation without breaking the application. Right. And then you can, you know, like tweak the network policy if it is not, you know, meeting the expectations, scope it down, scope it up and then see it. And then you can also apply it. Right. Like if I apply this it's going to start allowing connections to, you know, it is basically going to allow all the ingress and egress. So StackRex provides a very good tooling around, you know, elevating those pains of writing network policies. You can also generate network policies. Let's say you did not have any network policy or you had some network policies in place you can select a time window. Like let's say I want to generate a network policy based on the connections made to the app in past hour. Right. So I go to network policy simulator, click generate and simulate network policies. It says, you know, no network policies are needed to be created or related because literally I haven't allowed all. Everything opens. So yeah. So this is a very good, you know, tooling from StackRex to kind of, you know, play with network policies, you know, and build network policies. Yeah. That's awesome. So you can kind of just say, you know, look back at this sample of 24 hours, see what's happened. Exactly. It'll all be right there for you. That's awesome. And StackRex, I mean, has a couple of more things like network baseline. So I mean this demo has not been running for a very long time. I just spun it up right before this meet. So basically something like we have an observability window during which we observe the connections to an app and kind of lock it down and any new connections, you know, or any connections deviating from that baseline are highlighted as anomalous connections to basically asking you, hey, is this something you anticipated? If you anticipated it, okay, you can mark it as a baseline, you can move it to the baseline. If not, then probably you'll need to update your network policy because, you know, someone is trying to reach to your app. Right. So that's, you know, another cool tooling from StackRex, you know, to observe beyond the period of like, you know, you have applied the network policies, but what next, right? Yeah, and like, can StackRex highlight abnormal activity? So the, so right now, I should say advanced cluster security, I'm sorry, I keep saying StackRex. Advanced cluster security. I'm wearing a StackRex sweatshirt. I know, it's throwing me off. So we do not analyze packets. So we observe connections, you know, we observe the connection information basically the endpoint, you know, like the endpoint information, the protocol and things like that. We do not perform analysis on packets like, you know, we have like, I know there are some, you know, there are like these firewalls which perform packet analysis and kind of block or allow connections based on that. It's not that granular, but what we want to make sure is you can see the connections coming from an endpoint and make a decision whether that endpoint can be trusted. Allow it or don't allow it. Right. And once you have that rule for that connection, and since network policies are basically like sitting at the edge of the application, like the guarding angel, right? Even if someone kind of breaks into, you know, an app or, you know, a pod, it makes it difficult to move laterally, you know, kind of go to the other apps and, you know, kind of. That blast radius gets a lot smaller the tighter those policies are. Yeah, exactly. Like allowing, you know, some people do have or intermix. You know, dev and stage and prod across a fleet of clusters, not that, you know, there's anything wrong with that. But usually prefer product on its own cluster so you wouldn't want your dev stuff talking to your, you know, prod stuff or even your stage stuff potentially right like or there would only be one kind of lateral movement of package. You know, that's been tested and done from your CI system into the various environments. So yeah, there's a lot of power and a lot of potential here. And I think I believe, I believe that has been the underlying principle with, you know, things, Kubernetes, right? It has made it more explicit, you know, why namespaces, why application focus, you know, why things need to be, you know, focused around applications, it's because it should be in that way. Right. Your application is driving, you know, like should be driving, you know, the decisions on, you know, like how what's the environment you should be talking to and things like that. Right. And, you know, I've said this to some ops people before it's like Kubernetes forces you to understand applications better. Right, like you kind of makes it more every point. Exactly. And that's how it should be, right? Like we shouldn't be saying, you know, hey developer, what VM size do you need? And that be the extent of the knowledge that we have of that system, you know, other than patches that are applied to it or whatever, like we should understand the traffic coming in and out of it. We should understand, you know, syscalls to an extent of what's, you know, being called and if that's, you know, valid for that application. So doing the profiling is a really good feature, right? So you can actually sit there and say, hey, developer, you know, if you're not the developer looking at it at the time, you could go back and say, hey team, is this expected? Like, this kind of looks weird to me. Is that legit or not? Because you never know, right? Like, Kubernetes has been game changer. I have to agree to that. Yeah. I mean, yeah, so you've got some resource links here and I'm going to share the slides after we're done here folks, so Awesome. Don't worry about that. Yeah, I would like to, you know, make some like special mentions of the couple of things. They're like a couple of blogs written by my colleagues. They've also been submitted to CNCF around, you know, what are the best practices for writing ingress and egress network policies. And, you know, this GitHub resource is something that I, you know, love. This person is, I guess, network policy enthusiast and he has put out a bunch of samples, recipes, you know, like of network policies and how they behave. It's, I would recommend everyone to like check it out and it's good in, you know, kind of understanding, you know, and learning curve. And I mean, I put out some resources here but definitely this is not an exhaustive list and I do not want to stand behind any particular managed Kubernetes service or a CNI plugin. But, you know, like these are some most commonly used CNI plugins and, you know, kind of services. So, you know, good starting point. If someone wants to look at, you know, the CNI interface and things like that, you can go to their GitHub. I've also put links to network policy logging that is something new addressing the question like how should I detect intrusion, how should I add up my network policies. And the intrusion protection bit is pretty awesome because normally that's done like at your network edge and being able to do it right there and cluster is great. Last but not least, definitely, we look forward to, you know, contributors to the stack rocks community you can go to stack rocks.io reach out to us. We have blogs, you know, like if you have any cool ideas on talks things like that. And if someone is interested in looking at red hat advanced cluster security product, you can go to this link and request a demo. I guess you can also reach out to me and I can kind of moderate and forward that email to appropriate people. And yeah, we are hiring. We got job folks. If you love Kubernetes, and if you want to work in your, you know, security space, definitely go to this link. In other words, advanced cluster security and you will see a list of openings. Our team is looking to hire good engineers. So either you can go there or again, you can reach me out like LinkedIn or any other means and I'll make sure it's going to appropriate people in the organization. Well, man, our thank you so much for coming on really appreciate your time today. This is awesome. Awesome demo. Great work. And we'll see you will see y'all in a next month. I think this is monthly show. I forget. Yes, yes, so many shows. So yeah, folks, if I don't see you between now and next time, stay safe out there and Amanda, thank you again for coming on. Really appreciate it. My pleasure. Thank you, Chris. Have a great day.