StackRox Office Hours, 16 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: StackRox Office Hours (E3): Kubernetes Network Policies

Description

An important step in securing Kubernetes is reducing the attack surface by enabling network policies. But it's easy to make mistakes in building those YAML files.

Join our Office Hours to get your K8s networking questions answered. We'll start with some simple practical steps to secure your Kubernetes first, and then take your live questions. Ask our subject matter experts about:
- Applying policies to isolate pods
- Best practices on ingress and egress policies

A

A

A

A

Good morning, good afternoon, good evening welcome to another episode of the stackrock's office hours. This is episode three and I'm here with amanda dewaktar to talk about kubernetes network policies, I'm chris short, your host with the most here on uh red hat, live streaming. uh Mandar introduce yourself to the audience. It's your first time on the channel, so you know feel free divulge.

B

uh Thanks chris uh for the short introduction, uh yeah hi, I'm mandar, uh I work with the red hat advanced cluster security team.

B

I joined red hat via the acquisition of stack rocks and I've been with stackrocks 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're in the bay area- and you know want to join with me, hit me up.

A

Nice uh things I used to be able to do um so: kubernetes network policies there's a lot to them right, but you're gonna break it down for us. So how do you wanna do this.

B

Cool, uh so what I'm gonna do is uh share my screen and kind of walk through a a short and sweet demo, uh not too complex. um Basically, it will take us through how to write uh network policies and what are some things to uh look for when you're, writing uh and enforcing network policies all right. uh So, first of all what what are these you know, what is a kubernetes network policy right? So, uh in the simplistic terms, it's basically a means of controlling inbound and outbound traffic.

B

um You know from the parts perspective right to other pods uh or uh to the internet right, uh and this is achieved uh via something called as labels and selectors and widely used uh by various kubernetes resources right, such as services as well so kubernetes network policies and humanities like fogs, are very like uh they're, like the the network.

B

Policies are like the guiding angels wherever whatever is the label, you know the network and if the network policy kind of sees it uh satisfying it, it will just you know, stick to it, so that is one very crucial uh piece uh that is also important in you know identifying. How are you going to segment the applications right? uh So what I'll do now is basically jump into um you know demo. um So uh basically, let's create a namespace, uh so that I can uh you know, show whatever I yeah yeah.

B

So uh by default, uh no network policies are, um you know, enforced right I mean there are some um cni plug-ins um are managed, kubernetes services which, like deploy or claim to deploy, um you know default network policies, but those are essentially uh allowing all the inbound and outbound traffic right. So basically it's um doing it, it's not enforcing or it's not. You know limiting any traffic right.

B

So it's as as it's its behavior is, as uh there is no network policy right and uh kubernetes network policies being name-spaced um has actually a huge advantage, um although there are like some limitations, but it also has a huge advantage uh when we are thinking like kubernetes has been a game changer in like how we like deploy and maintain applications right or even to a certain extent how we write applications right. Everything is very application, centric right uh and the basic principle being.

B

You know um you know the applications of the parts uh like serve the purpose and you know disappear right and with this namespace uh kind of environment you know multiple teams, you know you know. Having these, uh you know uh different name space working in their own name, spaces kind of allows. You kind of provides this natural way of segmentation, and that is something you know. One needs to keep in mind uh when writing kubernetes network policies and how you can take advantage of network policies being name-spaced right.

B

We will talk about some limitations and how we can you know overcome them later uh in the during the demo, but you know uh for now: let's get started uh with that. So what I'm gonna do is I'm gonna create a very um you know, simple.

B

uh You know, uh environment in a mocking, there's like a database, there's a middle layer or the service layer, uh and there is the front end. You know the typical um okay.

B

Okay, so we are.

A

B

A

What is the db supposed to represent? Okay, so we were missing. Ns, okay, got it.

B

All right so uh le so we have our db, I mean it's essentially an nginx and app. You know which for uh demo purposes, I I'm I'm, you know treating it as um uh a db. Then.

A

B

Say we have a catalog service? Let's say you know, this is an application which is um um serving.

B

Which is basically serving um okay, so the issue was, we did not create it in the namespace.

B

All right all right, so, okay, let's get to what we have.

B

Oh interesting, okay, so there is the syntax error here.

A

Hot pot deleted so.

B

What I ended up, creating like a band.

A

B

Yes, the first rule right all right. uh So, let's.

B

All right, so, let's create uh the service uh called catalog, which is basically you know, acting something like you know, providing a catalog of products, um um and so what we have is now we have two parts. You know one is behaving as a database right. It's an engineering, fine and one is behaving as catalog right so right now uh there is no network policy enforced in this particular namespace right. uh So uh if I go into.

B

If I exec into one of the pods.

A

B

Yes, that is correct.

B

There we go and let's say we try to hit, you know google.com or something like that. You know I'm.

A

B

Reach out, I'm able.

A

B

Out to uh the internet- and you know I should be able to reach out to the other. uh You know pods. uh However, right now I've not exposed any other pod. um You know as service like uh so what I'll do is. I will expose um um db uh on port 80. Okay and of course we are up oops there.

B

Okay, so let's get all the parts again. However, let's also figure out what you know. Let's look at the ip addresses the plus stripe addresses that are associated with them 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.

B

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, and you know I think, unwanted things right.

B

So there are two approaches uh to this: when you're writing kubernetes policies right, um you can start off uh 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, uh let's say in a test environment, you know like it's not going to be used immediately right and what you want to understand is okay. uh You want to uh see how your application is. You know kind of reacting to that, deny all policy right. How is it failing?

B

You know where all it's trying to reach and another good thing to achieve accomplish. This is to have good logging right.

A

B

uh Whether if you're just failing, if you know silent logging or whether it's crashing and things like that right, but uh the other side of the coin is writing. Kubernetes network policies can be a daunting task and I agree to it. You know um many a times you know developers, uh you know kind of shared the responsibility to the administrators, um 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.

A

B

The other, the other approach is, like you know, put it in a uh test bed. uh You know with allow all and observe how the application is behaving. You know, for let's say uh an up a window. You know where all the application is trying to reach. So this is going to be your baseline right and identify if that baseline is even something that you anticipated or um even something that you expected yeah.

A

Right yeah, there could totally be something wrong with the image maybe reaching out and grabbing the.

B

A

Package kind of thing anything correct.

B

Exactly and then kind of reverse engineer: you know kind of scope it down by putting in place. uh You know some network policies, um you know um and things like that. So, for example, uh what I'm gonna do now is. uh I have okay. Let me first show uh I have a deny all policy here: okay,.

A

Pretty simple yeah.

B

uh Pretty simple: it's selecting all the pods in uh the namespace demo uh and not allowing any uh traffic right. So another thing another point I should be touching on is network policies um 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, can 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 a lot right.

B

So since there are no, uh the rules here essentially is telling, like you know, a lot of uh you know like we don't have any uh rules, uh so you know kind of block everything. uh So what I'm going to do is take that policy and reply.

A

To be angry, it's going to rebel.

B

Yes, I'm going to lose my I'm yeah, I'm going gonna lose my uh trp, my customer base when they're trying to shop from my wonderful catalog.

A

Yes, so catalog has a very beautiful index file.

B

Correct so let's go back um and um try to hit google. If I did everything right, we should expect this to time out right. Oh yeah, yeah right. We can also try to reach out to the other pod.

B

And it should feel all right cool so right now we have like a completely isolated uh name space, anything any new deployment um or any existing deployment or pod in this name. Space cannot have an inbound or an outbound connection uh to anything else right. So this is like you know, uh in ideal world. You know you would start here. You know, you know how your application is um supposed to behave. So you start from the most restrictive network policy and then kind of move outwards right.

B

So, uh as I already um okay so exposed uh the db service, um you know- uh and I want my you know- um catalog to basically query the db and you know like get some records out of it. uh So basically, what now I need to do is um allow ingress uh on db, like you know, from catalog right right, so that I can explicitly.

A

B

Those two exactly exactly so that I can fulfill those queries. You know. uh So, let's try to do that. uh I have um pre-built this yaml file. Writing yamls are kind of sensitive. uh I can understand a pain uh you know like even an indentation could make a huge difference. um Don't try.

A

The tool for that I feel like.

B

Yes, there are, there are there's. I would actually want to touch upon a tool that I came across and I've been using it, which kind of elevates some pains of you know writing network policies, but yeah we'll get get to it: okay, cool! uh So let's look at this.

B

What this policy is informing uh right, so it's it's and it will be enforced in the namespace demo and on the pods uh which have label uh app is equals to them db right and it's a ingress policy right uh telling that okay, I love all the ingress from the pods which are labeled app is equals to catalog, and this is the scenario we want um to support right now right, so let's just go ahead and apply that policy all right.

B

So that's the db policy all right. So, let's see what all policies we have now in this particular namespace.

B

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: uh traffic to uh the pod db right. So one would question like you know how you know what what is an effective network policy like what should happen when I have multiple network policies right.

B

So uh one thing is out of question like I created both these policies. Scope to this name says for this namespace demo right so the namespace policies, um uh the effective namespace policy, is basically the disjunction of all the rules. So basically, um if I have a 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.

B

A disjunction, uh you're gonna, what's gonna happen is the effective network policy is going to allow uh ingress. uh You know for that particular form. So that's how network policies work and how it plays. um How is it how it is important is um 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.

A

Complexity leads to mistakes exactly.

B

Network policies, being you know, kind of a challenge in the first place. If something breaks it's gonna, be uh you know difficult to identify. You know how it's you know. What rule you know what's rule is breaking you know things like that, so have network policies scoped to the functionality like what did it, what you know what's it's supposed to do you know if it is supposed to work on a pod like, let's say in in this case a db pod. You know scope it down to that uh deployment.

B

That pod, you know, is it supposed to allow ingress traffic egress traffic. You can have those you know have this, have this segmented out so that you know you can uh revoke like take out some network policies. If something breaks- and you know, work your way through debugging right so the first.

A

B

Of the important rule is, you know, try to keep it simple right, so I have an ingress policy. um So um does that mean? Let's, let's try to you know reach out to db.

B

Okay, let's see if it's gonna work all right. It's not! Okay! Let's, uh uh let's um pick up the.

B

Pick up the ip address and you know try to.

B

Get to it, okay, so I have an inverse policy on db, but somehow I'm not able to uh reach it uh via. You know, uh catalog, you know from catalog uh and the answer is you have a umbrella network policy blocking connection for all the other? You know pods, you know so now. What I have to do is, I have to explicitly add a network policy to allow egress from catalog right so that so when you're writing network policies, it's it's almost like you. You define the behavior on both the ends. You you right.

B

You have an ingress policy on once on on a pod, you kind of um have to have, like a you, know, a egress policy, a complimentary egress policy on the other end with you know, which, uh which you want to communicate with us. So.

A

What I'm gonna do is two-way communication, so.

B

A

B

Exactly and the reason why is uh I started off with the more you know, uh most restrictive policy right? If I remove that restriction right, then I all uh I can reach uh to db from catalog and you can. We can uh walk through that as well right, um 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.

B

uh You know through these explicit rules in the network policies right, so I have this uh network policy for catalog. uh Again, it's saying you know allow all the you know. I love the egress from catalog to the pods. uh Having a label app is equals to db.

A

Right, the port numbers 53.

B

That's a very good observation: there: okay.

A

B

uh Writing ingress policies has been like is traditionally uh kind of straightforward, um but when it comes to egress policies, it becomes slightly challenging uh because, um 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 uh you know gke bucket to get some? You know data for at start-up time, uh but the most primary thing is most likely it will.

B

You know it has to reach. um It has to be able to reach to a dns server right to be able to resolve. uh You know what you know: the pods uh and external endpoints as well. So if I correct right so, if I do not have this rule right, basically, if I try to reach uh the pod, uh you know using um like the the name right.

B

It's gonna fail right because I cannot reach to the dns and that's the most important uh note to make right when you're writing an egress policy uh make sure you can reach to uh the dns server right, whether it be cube, dns or other uh dns servers that you're used make sure you're not blocking that right. um Now there are caveats of this rule. Basically, it's allowing you know uh traffic to all the parts on 453.

B

You can scope it down.

B

You know by labeling the cube system name space um and you know, like kind of uh making the rule translating the rule to you know only reach out to cube dns and you know, keep system name space, but for now I'll just leave it as is and move ahead all right.

B

So let's apply that and now we have free 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.

B

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 uh this is you know. This is like a very uh simple uh kind of um demo. I had. I have like couple of more uh network policies here. uh I would specifically like to you know, like uh maybe show another one um right. So, as I said you know, yaml can be confusing. uh This is another form of.

A

More than one way to yamala cat yeah.

B

Yes right so so it's um I came across like a very there's, a very good uh meme out there, which says, like oh there's, like a kubernetes which, like a cat, is wearing cube right, yeah and it says, like um oh, you said like just yaml- would be sufficient right, but it's not the.

A

B

So both are essentially denying uh you know the uh traffic both ways uh on all the parts in this namespace demo right, uh but you know like there are different ways how it it it is written. So you know knowing like testing out the network policies is always uh you know critical.

B

uh What you're writing you know the yamas? um It's it's very important. Like you test out, uh you know how uh the the yaml that you have written you know ends up being right. um So yeah I mean this was the short and sweet demo. um I had um yeah and let's um I mean this is an office hour. uh I believe yeah.

A

Yeah, if you have questions, feel free to ask them um so amanda. 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 um on port, 80 or 443. Depending upon the situation, um I mean. How else can you like make that rule better, tighter kind of thing.

B

That's that's a good question, uh so let's uh open up that yamo right. So there are some prerequisites to do that right. Since network policies are tied to labels and labels on you know the parts.

B

First of all, you need to make sure that you know if you want to scope it to something make sure that that particular pod has appropriate labels right uh generally users, you know, create namespaces and you know: do not label them uh people, folks, like label uh pods, uh you know deployments and other things um because most likely they'll expose it through human services like load, balancer and things like that, uh but namespaces right. So then you also got to like uh label the namespace right. So uh let's, uh let's actually try to do that.

B

Let's see if I can actually do that without okay, so we have cube system okay, so I'm going to uh list p parts in the cube system right. So we have the cube system uh sting right there. uh Let's describe cube system.

B

And see if it got anything nope, uh so we have this label namespace metadata, styrofox, io, cube system, so I have um 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 uh let's pick that label and um 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.

B

Okay, so scope it down right. So I want to scope it down, uh match the label.

B

Blah blah blah right name space is equals to so answer right. So now what so? Now we have scope it down slightly right. So what it's telling what this uh network policy is um informing is allow um egress traffic to put um 53 for all the pods to all the parts in namespace. You know having carrying this label right all right, so it's still like okay. You know you can still reach out to all the parts in your dns namespace right, so we might need to uh scope it down further right.

B

So let's say: uh let's describe you know uh what cube dns looks like.

B

B

All right, okay, so huge.

A

Right, yeah, yeah.

B

So uh there's a label here which we can likely use. um You know um its app is equals cube dns. Now uh I want to also talk about. You know labeling. You know what what what are some basic.

B

Rules uh or um tips that one should you know be aware of when you want to segment the network policies or basically your applications, all right, so I'm going to cut it again just to 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.

B

Having cube the uh kids app is equal to cube dns label um on um uh sorry in namespace having that particular you know uh label right, but the caveat to this is: although I've scoped down my network policy- and if someone is going to um you know, add a pod uh with the exact same label, it's going to start allowing egress traffic to that label as well right that part as well right.

B

So there are two parts to this right: writing, network policies, enforcing 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 right. Otherwise, you know anyone having you know those permissions uh to introduce new network policies or introduce uh new uh or update the pods uh with new labels can basically go around the wall that you're trying to create right, and there are a couple of ways uh to kind of uh achieve that enforcement.

B

You can have um an admission controller in place um that kind of um restricts. um You know, creation of um so you know like updation of those resources or like um creation of network policies, um like you know, uh or you can also use like kubernetes, our back rules um to basically kind of scope down.

B

um You know who can do what right like remember the principle of least privilege the 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 um let me just show, I love all. If I go ahead, if someone is able to apply this policy, all my effort is waste.

A

B

Right because it's going to allow all inbound and outbound traffic, uh you know to this particular namespace right, so so so they're like you know, so that that's another important thing you know how you are going to complement uh the network. Security through network policies is kind of having some kind of enforcement um and adhering to the principle of release.

B

You know privileges. You know uh so that people cannot go around uh that wall you're trying to create.

A

Yeah, don't hit the all the play-all rule um question in 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.

B

Ingresses and.

A

Are back and all that fun stuff, but is there a network policy for that.

B

uh There unfortunately, no uh yeah there, no uh it's because network policies are uh something you know, application of it like they're meant to be application. Hours they're meant to be focused on. um You know, application right what works in one environment? Well, let's say you have cassandra and things like that, and you know like uh you. What works for that particular environment will not work for other environment, but there are these. You know basic uh there. Are these basic uh points right? uh What to look at right?

B

uh Let me, actually, you know, go um to that right, like this slide. Okay, now this is not an exhaustive list. uh I've just tried my best to in a list couple of things which I feel uh are important to look at when you're writing network policies right.

B

So, first of all, you don't want to uh block reaching out to, like you know, kubernetes api server right uh dns, like the dns servers. You know that your application is going to depend on uh the you know the ports that you want open so that, if it is serving uh serving, you know like workloads on the internet. You know you want to keep them open right. uh If you have like exposed behind a load balancer, maybe you want you know like most likely.

B

You will want to have these health and health check endpoints uh open so that you can know you know whether your services, you know your apps, are healthy things like that.

B

So they're, like some, you know uh basic the basic things that when one can start at um and like work their way towards it and like again reiterating um you know like one can deploy um the application in in a test page like observe how it's behaving you know for a certain time window and identify you know how you know whether it's meeting uh the expectation right and kind of reversing like start your way, um you know backwards, like start scoping it down.

B

So definitely I mean testing network policies is a crucial thing. You do not want uh to break applications in production, um yeah.

A

Yeah, don't start testing things on broad right, but.

B

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 um to you know kind of start, moving the security from um 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.

B

You know the best right, uh so you know it basically shifts uh enforcing security. uh You know in the early phases of applications life cycle right. You know it very well start in you know during the development of the application as well right. So that's uh I see it as an advantage. I see kubernetes network policies and the nature of it being um the declarative nature of it uh being an advantage.

B

You know to you know, allow anyone uh like to enable the developers to kind of you know take that uh responsibility, shoulder that responsibility to enforce security early on.

A

B

A

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.

A

Yeah so routes and cooper and openshift land are like ingresses and kubernetes land. They actually predate ingress. um So this is something that red hat had to create to.

B

Satisfy customer.

A

Need when openshift was launched um 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 making sure that you know the the ingress is good to go. It's not.

B

Opening things as.

A

It shouldn't have open, and you know you can do that with a number of you know, different and.

B

A

B

Yeah yeah there are, like you know, like um not. Everything is um green with a network policies like um there are some pain points right, like uh network policies are name space, name, space, scope, right, scalability right is uh one of the challenge right you, for example, you know the standard dns like allow egress traffic to dns. If something uh probably would be natural to uh throughout the organization right uh and teams deploying their applications in different name spaces, you know, uh might most likely you know want to have that template right.

B

um So there are, you know like each. um There are these cni plugins and different managed. Kubernetes services. Have you know different choice of cna plugins, uh but these cni's cni plugins have uh something called as like global network policies or like cluster level, uh network policy and hdmi plugin uses different terminology. You know that kind of addresses uh the concern of scalability right.

B

Let's say if someone uh wants um a workflow such as you know, when any application that is deployed uh must you know have, uh must allow egress to you know the dns servers of that organization. um Things like that right, so these cni plug-ins kind of enable it and the kubernetes network policies work in um work. Handy-Down with, like this network, uh cni plug-in the cns specific uh network policies right. So it's it's a it's a complimentary, um um you know feature uh and uh most cni plugins.

B

um You know like have you know things like visibility as well? Right, like uh you, have deployed a network policy. What next? Should you sit back right? That's that's some! That's something um 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, uh for example, like celium, has a very awesome.

B

um You know like um network observability, I'm not sure whether um it's like a paid thing or not, but uh they have like some um 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. uh I believe you know it it's because you know, there's ebpf uh and ebpf has been like you'll see it being used uh in more and more places, because you know uh it the enriched data that you can get uh using.

B

That um has been advantageous. I think gke data data plane v2, um has that feature as well. Celium has calico also introduced that so uh kubernetes network policies uh limit their limitations. You know, look at you know: cni plug-ins, um um their network policies. You know to kind of reduce um the repetitive work of let's say a cicd pipeline. You know things like that and observe observability right. So that's another um important aspect to that.

A

Very good point: uh I just linked and chat folks to the uh last episode where we talked about uh evpf um and implementing security and monitoring on kubernetes with it so uh feel free to check that out at your leisure. um You can always find us at our webpage, which is such a simple link here.

A

Live streaming type today, great, um so yeah, no other questions from the audience. I I feel like naveen. If I haven't answered your question, please let me know um and I'll ask uh mandar, but he was asking you know: how do I get things out of the cluster basically or have access to things um if a connectivity.

B

A

Occurred like so uh between, I guess. I think he I'm thinking he means uh between nodes, but.

B

How do you like diagnose if there is a failed connectivity failure.

A

Yeah like he wants to know, what's the source ip.

A

Yeah, so I'm confused by.

B

A

So all right, I'm.

B

Trying to answer.

A

It while being confused.

B

Let me think of like. Let me put out some couple of points, uh so is: um can you access um the you know um the audit logs, the you know, um the community? The api server uh maintains a log of all the um um you know, requests that are coming to it right I mean essentially when you, when I'm running a cube cattle, you know create namespace or git bar.

B

It's essentially, um you know a rest call to the um api server right and everything gets logged in there um managed uh kubernetes services most if I'm not wrong. Most like most likely have the uh feature the logging feature turned on by default. So that's like uh one good starting point uh and network policies are not going to uh deny or not going to block.

B

You know any communication between the pods and the node that the part is residing on right. uh So if you can get on to the node, you know um you can, you know, run queue petal uh and if you're having admin privileges, you can keep cuddle and kind of diagnose, get the application logs and things like that.

A

So I've got a question in here: uh does stack, rocks or now advanced cluster security help automate the management of these network policies rather than having to manually, create them.

B

That's a good question and I would love to show stack, rocks or acs.

B

Let me share my screen awesome all right.

B

uh Let me know if you can see the advanced cluster security, okay cool, so uh one of the most uh you know talked about a feature of stack rocks. Is a network observability uh network segmentation right, as you can see here, um I'm not sure if you can see where I'm hovering, uh 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 uh connections that are active right now.

B

You know, uh so that's like a good way of uh you know of observing, like you know how my applications are connecting. Let's say 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 um a kind of scoping or uh making it explicit to which uh ciders your application is trying to reach out to uh you know outside your cluster.

B

So this is about active connections. So, coming back to that question right uh so a loud view. Kind of provides uh uh that the space of uh how your applications or what all kind of connections your application can have right. As you can see like you know, there are different. uh Let me zoom in um so these um boxes or the squares are name spaces and these um you know filled circles or dots are your cards and deployments, um um and each of them is having like a different um legend right right.

B

uh So, basically, as you can see, if I hover over db, um if, if, if we 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- it cannot reach out to the external world. You cannot see that arrow right. uh So same thing like uh you know, like uh you know, other part, I think this when this was the one which I created now uh you can go to network policy simulator.

B

uh Let me let me filter down first, so that it's.

B

Okay, so we have this demo cluster and the associated uh namespaces. uh 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 uh to the namespace demo right. uh So I can see what are my you know: network policies um in this particular name space.

B

I can edit those network policies and upload them here uh and see uh how it is you know taking effect, um you know how it's changing right, so uh there are ways to basically like upload um a network policy right. Okay, let me see if I can navigate to the folder. uh I believe.

A

B

Allow all I believe we had not applied.

A

No, we did not apply that, but all of a sudden, your db, can talk to the api server. That seems crazy right.

B

So this is another way uh to you know, uh make sure like how your network policy is 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, uh you know, meeting the expectation scope it down, scoop it up and then see it, and then you can also apply it right like.

B

If I apply this, it's going to start allowing connections to uh you know it's basically going to allow all the ingress and egress so stack rocks pro is a very good tooling around. You know um alleviating those pains of writing network policies. um You can also generate network policies. Let's say you did not have any network policy or you had some network policies in place.

B

You can select a time window um 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 have enough allow all of.

A

Everything open so yeah.

B

So this is a very good. uh You know, tooling, um from stack rocks to kind of you know, play with network policies, be you know uh and build network policies. uh Yeah.

A

That's awesome, so you can kind of just say you know. Look back at this sample of 24 hours see what's happened.

B

A

Exactly it'll all be right there for you, that's awesome exactly.

B

And uh stackrocks 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 uh this uh meet. um So basically uh something like uh we have an observability uh window during which we observe the connections um uh 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?

B

If you anticipated it? Okay, you can mark it as a baseline. You can move it to the baseline. If not, then probably you will need to update your network policy, because you know someone is trying to reach to your app right yeah. So that's you know another cool, uh tooling, from stack rocks. uh You know to observe beyond the period beyond the period of like you know, you have applied the network policies, but what next right.

A

Yeah and like can stack, rocks, highlight abnormal activity so.

B

uh The uh so right now.

A

I should say advanced cluster security. I'm sorry, I keep saying advanced cluster security.

B

I'm wearing a stack rock switch. I.

A

B

A

Throwing me off.

B

So we do not analyze packets, um so we observe connections. um You know we observe um the connection information. Basically the end point you know, like the end point information the protocol and things like that. uh We do not perform analysis on packets. Like you know, if you have like, I know there are some. You know there are like these firewalls you, which perform packet, analysis and kind of block or allow connections based on that. uh It's not that granular.

B

But what we want to make sure is, you can see the connections um 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 um at the edge of the application like the guarding angel right, um even if someone kind of uh breaks into you know an app, uh you know a pod, uh it makes it difficult for uh to move laterally.

B

You know kind of uh go to the other apps and you know kind of.

A

That blast radius gets a lot smaller, though exactly tighter those policies are yeah. Exactly like allowing you know, some people do have or intermix right. um You know dev and stage and prod across the fleet of clusters. Not that right, you know, there's anything wrong with that, but usually prefer prod 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.

A

You know that's been tested and done from your ci.

B

A

Into the various environments, um so yeah there's a lot of power and a lot of potential here, and I think I believe.

B

I believe that has been the underlying principle uh with you know things kubernetes right. uh It has made it more explicit. You know why namespaces, why application focus? You know why things need to be. uh You know focused around applications, it's because it should be in that way right. Your application is uh driving. uh 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.

A

Right- and you know, I've said this to some ops people before it's like kubernetes forces you to understand applications better right right, like you kind.

B

Of makes it more at every point exactly.

A

And 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.

B

A

For that application so doing the profiling is a really good feature right, so you can actually sit there and say: hey developer. Can 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 right? This kind of looks weird to me: is that legit or not, um because you never know right like.

B

This has been game changer. I have to agree to that yeah I mean yeah.

A

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.

B

uh Yeah, I would like to you know, make some like special mentions of uh the a couple of things uh there are like a couple of blogs written by my colleagues. They've also been submitted to cncf around. You know what are the best practices uh for in writing, ingress and egress network policies- and um you know this github resource- is uh something that I you know love um this person is, I guess, network policy enthusiast and he has put out a bunch of samples um uh recipes.

B

um You know uh like of network policies and how they behave. uh It's. I would recommend everyone to like check it out and it's good uh in you know kind of understanding. You know and learning for, uh 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 man particularly managed kubernetes service or a cni plug-in, but you know like these are some most commonly used. Cni plug-ins and you know uh managed services, so you know good starting point.

B

uh If someone wants to look at, you know the cni interface and things like that, uh you can go to their github. uh I've also put uh links to network policy logging. That is something new um addressing the question like how should I detect intrusion? How should I adapt my network policies.

A

B

A

That intrusion, detection 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 right. So.

B

um Last but not least, you definitely uh um we look forward to you know contributors to the stack rocks community. You can go to snackrocks.io reach out to us uh write blogs. You know like if you have any cool ideas uh on talks. Things like that and uh if someone is interested in looking at red hat, advanced cluster security product, you can go to this link and request a demo.

B

um I guess you can also reach out to me and I can kind of moderate and forward that email to appropriate people um and.

A

B

A

We got jobs folks.

B

If you love kubernetes uh and if you want to work in you know, security space definitely uh go to this link um put in the keywords: advanced cluster security, and you will see a list of openings.

B

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 uh it's conveyed to appropriate people in the organization.

A

Awesome amanda. Thank you so much for coming on really appreciate your time today. This has been.

B

A

Awesome demo great work and uh we'll see you and well we'll see y'all on a next month. I think this is monthly show last I checked. I forget yes, yes, so many shows um so yeah uh folks. uh If I don't see you uh between now and next time, stay safe out there and mandar. Thank you again for coming on really appreciate it. My.

B

Pleasure, thank you chris, and have a great day. You too,.

A