 Welcome everyone, I hope you had a great lunch and our goal is to defeat the lunch dip and talk about network policies the not so hard way With Sillian why it's different and how you can effectively secure your workloads in your clusters today with me is Tracy home So like to introduce Tracy. She's going to run the actual lab with you guys I'm going to first start with the presentation. My name is Raymond. The own I'm from my surveillance I'm a solutions architect and I hear today to talk about network policies So the agenda first we'll talk about silly mini BPF as an introduction Talk about security and observability. What features Sillian has for you to secure your workloads to observe your workloads then a little bit about strategies for designing and working with network policies after which we Sure have a short demo using how will you why as well? after which we will dive into the lab with Tracy and we want you to also do the lab alongside with us and For that purpose, I would like you to ask already to go to ISO failing dot-com forward slash labs and Then starts the getting started with Sillian OSS labs It takes a few minutes for the labs to be actually be created It's an actual lab running on kinds based clusters for that to be provisioned with a group It makes sense for people to already start it. Just wait to continue before Tracy will start the lab with you Okay, back to the presentation Cool Sillian any BPF introduction. So we're from ISO failing where the originators from Sillian We invented Sillian and donated it to the community and Sillian is widely used Amongst multiple different environments for different use cases among security Sillian is based on eBPF and eBPF is a technology What we like to say is that it's a technology similar to JavaScript to the browser Sillian or eBPF is to the kernel and it makes the kernel programmable in a very efficient way without actually changing the kernel and It's very powerful because it can run on kernel events. So anything a process opening a socket or Network device sending a packet. Those are kernel events where we can attach eBPF programs on And that's very powerful because we can do things with that. We can expose metrics We can see identities. We can observe flows as we will show today Sillian is built on eBPF and you don't have to be an eBPF engineer to use Sillian because Sillian abstracts complex technology for you It will automatically program the required eBPF programs Depending on what you configure and it provides a software defined networking solution for the cloud native age including external workloads and obviously in Kubernetes environment it takes care of Identities instead of IPs Sillian has a lot of Functionalities and features of which of networking Observabilities with Hubble which we'll show and demonstrate today as well We've introduced a service mesh solution, which is a sidecar less Implementation powered with eBPF to accelerate the service mesh capabilities to do layer seven path-based routing Providing ingress out of out of the box without using a sidecar which three to four times improves latency and performance and obviously removes Resources you may need for running sidecars in your clusters So let's talk about security with Sillian. Sillian provides an identity based Solution in Kubernetes clusters IPs come and go. They are ephemeral such as with the workloads What Sillian does is for each unique set of labels attached to your workloads think about tier front-end application and genics that you unique set of labels will result in an identity and Sillian uses this identity to attach this identity using eBPF to the actual IP packet and We're able to also observe and identify indent that identity for example on the destination so a front-end reaching out to a back-end means that the front-end gets that identity attached and The back-end will be able to inspect that identity when to get traffic goes Inbound and depending on the network policies you configure it allows or denies that traffic Furthermore Sillian provides API aware authorization Now what that means is that not only layer three on my piece or late and or layer four on ports We also provide layer seven rules and capabilities to be able to filter HTTP request on specific calls methods on specific paths and This is an example of a Sillian network policy where we have a HTTP aware rule for a namespace demo where we apply this rule to an applications called server match labels Equal server and then have a rule ingress from endpoints clients to port 80 and then notice the rules HTTP method get on the path forward slash so this is a rule example where we only allow this specific Method on this specific path and nothing else in the lab. You will see there are some some examples of this as well Another example is a constant Cassandra Sillian network policy So besides HTTP we also support Cassandra to only allow a specific Career reaction on a specific table. We can also filter on Kafka topics or GAPC calls amongst others Furthermore, what's very powerful is the Sillian network policies which are DNS aware, which means that for example, you're running Storage workloads on S3 buckets as you may know IPs of those buckets change all the time So securing those resources is hard to track Using fully qualified domain names. However, you can filter traffic to specific buckets And that means that using DNS aware Sillian network policies. You can secure access to a given fully qualified domain name how it works is that one front end does a query for for specific domain we're able to intercept that and Based on that using eBPF allow or deny that specific traffic Besides lay free layer layer free matching capabilities We're also able to match on things like cloud providers labels such as instance labels subnet subnet names subnet tax Or other security group names as well And we also have logical identities things like worlds or local hosts or remote hosts Ingress and such which are also useful in some specific use cases working with Sillian network policies Sillian network policies are very powerful, but without the right observability tools. You're still lost Applying a specific configuration of security on your workloads Sillian Sorry How will you how well is our? observability solution on top of Sillian and we provide a UI which shows a surface dependency map Allows you to see the flows between surfaces On protocol level depending on the policies you set you can even see flows for layer 7 rules as well for more advanced Use cases troubleshooting or inspection We also support a CLI which allows you to also do extensive filtering and also be able to allow output to Jason And the Hubble metrics components everything related to getting metrics out of Sillian and Hubble and export them through Prometheus to Gravana for example or in advanced use cases also to see platforms to get alerts For example in Splunk on security incidents This is how the CLI looks like I'm not going to talk a lot about this because you will also discover this in the Lab, but what you will see and what's important to notice is that we able to identify The HTTP calls the fully qualified domain names being accessed and also the identities being attached to those workloads This is a quick example of a service map where we can see the dependencies of services that the Communication between services and also note that in some examples for example the core API We can see these specific URLs and specific methods being used to reach that service And this provides you the tools to get started with your securing your workloads without breaking your applications This is an example of Hubble metrics if we have time today I have also an example of policy verdict metrics. So using Gravana We're also able to track policy verdicts things like allowed or denied which should match your policies where you can see how many Policies are actually matching and also what kind of domains are being reached out so Working with psyllium network policy or network policies in general can be a very big challenge You don't want to be in the way of your developers, but on the other side you have requirements that you need to secure your applications If you deploy a deny all policy it's most likely to become very difficult and hard to for each independent service and application to Introduce the psyllium network policy and to troubleshoot that You also need to keep them up to date You need to know when an application changes What is actually changed and and what you need to do to change your psyllium network policy and How do you prove that and what are the risks? so our goal of today is also to talk a bit more about some mechanisms to Understand our approach this challenge and to be effectively secure workloads, and I want to talk about four risks and Risks exposure obviously from the internet where you're exposing services. That's a huge risk From internal networks if you just expose from any destination that can be a risk people accessing data Which they are not allowed to if we look at the intra cluster or between cluster we have lateral movement risk or egress risk for workloads reaching resources in external network for example a physical database Obviously things like reaching back to internet as well. You want to avoid people being able to open a reverse shell for example So the goals to reduce you unused access Which creates exposure without being required for the application to work So we also want to reduce the blast radius, right? so if a pot gets compromised it can expose or Move on to pots in its same namespace, but even but beyond namespaces or beyond clusters So we also want to limit the blast radius So there are different ways you can do it for example the denial is is very effective But will be very hard to work with so what we try to work with our customers is to get a starting policy Which is good enough? reducing risks only exposing to get started for example pots between and for Within a given namespace for posts being able to reach out to each other's to allow Service-to-service communication within a given namespace, but denying resin egress from a namespace Accept things for example Prometheus which needs to monitor workloads and obviously cube DNS being used to resolve DNS requests and then you can basically start with a course grained per namespace policy where using Hubble you can start with opening ports to Observe traffic and then moves move on to slowly introducing more specific firewall rules for for your workloads and the goal is then to move to a fine grade namespace policy Where you don't only allow on a specific IP IP and port But even better on a specific fuller qualified domain name and only allow an or expose a service through a low balance on a given port as such And I will show and demonstrate this a bit in a demo as well Obviously slave sodium can be very powerful in github's kind of operation DevOps security DevOps operations using github and GitLab integration using Argo or flux to basically automate PR from Celium network policies which have for example any as a destination or zero zero zero four slash zero and automatically Denied a PR for you to be changed to a more specific DNS DNS So with that I'm going to move to a short demo as an introduction to the actual lab So the overview is that we have deployed a namespace with a starting network policy which allows traffic from that namespace and I'm slowly going to use hobble or I'm going to use hobble to slowly introduce more specific Celium network policies to secure that namespace and eventually Remove the allow all rule to have that specific policy All right. Let's hope the demo gods are with us. I hope everyone can see this in the back Please let me know if it's big enough Little bit more. Okay, cool. Give me a second So I've set up a demo cluster on GKE Installing Celium 1.12 Also with hobble So I will demonstrate the application So this is a simple example. We see we've deployed this namespace called my app. We have a simple client server Application running and we can see traffic from the client to the server on port 80 most likely HTTP but we don't see it yet and TCP traffic And we see that the client is also reaching out to some kind of destinations outside the cluster Perhaps even on the internet. So we want to know more Looking on the flows the live flows. We can see it's actually public IPs. So We need to investigate that a bit So to do that we need to have some specific policies in place Is this big enough as well for the audience? Good Sorry So For starters, we want to see the external access so what I want to do introduce is that I'm going to introduce a Celium network policy which is going to inspect That's the NS traffic from that client. So what I do I select all endpoints Using this and then specify egress to allow access to cube system to port 53 but I also specifically have a Rules section where it specifically matches for DNS and using this wildcard. I'm able to allow DNS requests But I will also see The FQDNs being reached out to so I can take further action based on that. So let's apply this policy So it's the DNS demo I've applied it good Quick check of if I'm still in the same namespace I'm not actually Good to check that Let me first Change namespace. All right All right, so I'm play I'm applying this policy Now we already can see that Celium detects or hobble detects automatically that we're now reaching out to isovalent.com and Celium.io. So we have better information what this client is trying to reach out to So with this information we can make a more specific Informed decision on how to secure the specific workloads on the client side We do see that the client is not only reaching out to isovalent and celium But also to the server on port 80. So with this information, I'm now going to apply this Celium network policy Which is applied to the client? Note this ingress part using this I'll deny everything ingress for this specific end point and then egress I allow the server To sorry allow egress connectivity to the server on port 80 And I also need obviously to allow QP API access and Now I can actually add The two for loophole of my domain names piece where I only allow these two domains on port 4 for three like this So this won't change anything in Hubble, but I've applied this policy and next is the server part I want to secure ingress to the server and considering time I will start with Applying a policy on the server also explicitly deny egress connectivity But allow ingress from the client to port 80 So again, this won't change anything here And now I've applied a client rule a server rule a DNS rule Which should mean that I also have Secured all workloads So what I can now do is remove the two broadly specified allow all rule which I applied for the application to function And if I did things correctly, I should not see any drops And this means that now The client application is working the serve application is working and it is allowed to access external resources But let's say we have another application being introduced So let me quickly go through this and then So let's say there's another namespace another client application wanting to reach out to the server application and It's being introduced but We can now see this another app tries to Reach to the server, but it's not able to reach it We see drops and we can click on Hubble UI to zoom in on this another app workloads And you see drops and forward you may wonder why is that? Well, it's because the another app Doesn't have any policies applied to it yet. So egress from that app is Allowed, but ingress on the surface obviously denied because we didn't allow that specific destination So let's suppose this is required. So we need to allow this That means that we need to go back to The policies directory I've stored them So let's allow We know this endpoint will we allow this another app to reach from the namespace another app To port 80 and we also know we've been informed that they are running HTTP For access so we also allow that only HTTP on layer 7 is allowed So we're updating the server policy and now we can check in Hubble What this means I think the drops are already gone. Yep, everything is being allowed and We also see we now also have the layer 7 visibility because we can see that we This client another app client is reaching on does a get call on the default path Okay, so that concludes the demo a way for securing your workloads and From here, I will hand over to Tracy to go through the lab with you. So you get more hands-on experience yourself With a star wars based example secure and get workload Tracy here you go. Thank you So if you haven't done that already go to ISO valent.com forward slash labs to start the getting started on OSS lab We also have doffy if you have an issue Doffy's happy to help as well If you run into an issue in the lab, let us know And we can support you. I'll come to you to help you as well for those of you They can't see doffy space. He was just as surprised as I wasn't here that way Um So, let's say question Hold on just a second Yo Has anyone here not ever touched psyllium like raise your hand. Oh This is gonna be good. Okay. Has anyone in here never used instruct before Okay, so first things first Ray told you all about the URL when we first started if you hit launch When he first started talking go back out and go back in what instruct will do is it when you get to a certain time? limit it will kick you out and I don't want that to happen to you all while you're in the middle of the lab the URL again is ISOvalent.com forward slash labs and The very first one on the left side of the grid is getting started with psyllium OSS cool This is not a terribly long lab So if you if you do have questions while I'm going through Ray is still miked up He can help Duffy here with the Amazing black hat that he is known for will also help. You want to see it. See it. Okay, I got you Thank you Let's see what I can do. I never use this app, but it might come in handy this time. That's not helping No, that's because I'm not in the font Y'all saw nothing That's the URL How many advocates does it take to change the font size on something? Can everyone see it now? Yes, no Yes, okay, this is getting started with psyllium lab as you all will know I will read the majority of this just in case. I don't know if English is everyone's first language So therefore you those of you that are watching hopefully you can understand me the other thing is I am a fan of typing things out So if you've never used instruct before when we get to the first page I'm going to show you something to make sure you don't miss any of the commands. That's that are on the right side of the page so ensuring security on Kubernetes How do you enforce policies troubleshoot the network and stay secure with minimal effort a New approaches needed you get to talk about psyllium today. I'm not going to go through this However, Ray just told you all about this that would be redundant. You are free to review that While my environment is creating because that's going to take about a minute or two Yeah, Ray you you covered all of this. Thank you And you all have already met Hubble so hopefully you're getting into the labs while this is happening Oh, yeah, so you will also have quizzes I'm going to need you all to yell out an answer or a letter or something to make sure that I'm getting green before We go through so just know that I will stop and ask And yeah, now we just have to wait. So sorry about that I would sing background music, but I'm horrible. I thought Ray. I think you jinxed my environment set up No, it's it's creating. It's just taking a minute. That's very helpful. Thank you So maybe it's just me There we go. All right, so start. Phew. Sorry about that. Thank you all for being patient I didn't have any jokes ready. I apologize So for those of you that never use instruct if you look on the right side where you see the kind cluster You'll notice there are drop-down arrows for everything if you want to work ahead Absolutely fine. However, make sure that you scroll down because some of the text will hide Things that you need to expand before you can move on got it Yes Yes, okay. Good. No, it's all right. So We're running a kind Kubernetes cluster and on top of that. We're running psyllium. So while the client kind cluster is finishing It's start Let's look at the config I'm not typing that up And that is too small for those of you that are trying to see that Let's do this Is that better or worse? Better. Okay. All right. So in the node section, you can see that the cluster consists of three nodes one control plane node and that's running the the case control plane and Two worker nodes that will use to deploy the applications and the networking section in the config file The default CNI has been disabled So the cluster won't have any pod network when it starts instead psyllium is being deployed to the cluster to provide This functionality. So psyllium will be your CNI. So let's see if the kind cluster is ready Hopefully doesn't take as long as the lab did to start up and we'll make sure that the cluster is running properly We're gonna list those nodes Control V does work in this for pasting. You can also just copy the command whenever you see the code the Copy button should pop up so you can copy it that way if you'd like All right, so you see all three of the nodes appear. So you see those on the screen all are marked not ready That's normal the CNI is disabled and after this page. We're gonna install psyllium so if you don't see all the nodes they might still be joining the cluster and Hey, since we have a cluster, let's go install psyllium All right So what we'll be using if you've ever if you've never worked through one of our Getting started guides in the docks. There are a couple of ways to get to this point There's actually a brew command install psyllium or at least get the agent there Or also like a curl command. So that's what's already been done in the background after that step is where we're at. So psyllium CLI tool is provided to install and check the status of psyllium in the cluster so we can know what's going on but it'll also It helps us install and update psyllium, but you can also like enable hubble and cluster mesh from the CLI So let's go do some of that and you are literally typing psyllium install That's gonna take about 3045 seconds to get done And it will let you know that it's installed and ready after that We can check the status to make sure that everything is is nice and healthy and and happy Everybody with me so far Yeah, okay cool Also, if there are any terms you don't understand again I have very very nice people in here Including some that probably have on shirts that are hiding and don't want to be called on in case you need help for definitions or anything like that Honestly think psyllium is mad at me, right? The labs don't like me anymore There we go. I have to fuss. Okay. It'll even tell you what to type to to view the installation help So I'll just follow the instructions from the command line So let's do psyllium status and see what's going on all right so the very first two things you see are that psyllium isn't okay and Operators doing okay. We haven't enabled hubble and we haven't enabled cluster mesh. So those are going to show as disabled So now that we're functional Let's go deploy the demo app. I love instruct that tells me well done Thank you instruct. Ah quiz number one the psyllium CLI Allows us to and we can have multiple answers if needed. So which one should I click first? Top one. All right Anything else check the psyllium status that that was somebody said middle one. Okay Anything else? No All right, let's see what happens Goal star. Thank you so much. If you don't already know we're fans of Star Wars here. It's fairly So everything going forward if you're a tricky I apologize in advance So to learn how to use it in force policies with psyllium. We have prepared a demo example We're gonna have three microservice applications. That's gonna be the death star a tie fighter in the X-Wing Death Star service is it runs the HTTP web service on port 80 That's exposed as a Kate service to load balance request the death star across two pod replicas The death star service provides landing services to the Empire spaceships so that they can request a landing port The tie fighter pod represents a landing request client service on a typical Empire ship X-Wing represents a similar service on an alliance ship And with this setup we can test different security policies for access control to death star landing services It's just like your house. You don't want people going in and out of your house. They don't that shouldn't have a key, right? It's basically what we're doing just the Star Wars version. All right, so Let's check to make sure that all the components have been properly deployed. Let me move this over So you all can see some of us. There we go It may take a few seconds to display the results. You all are very patient and have been so I don't think that's gonna be an issue All right, so let's successfully rolled out. Let's deploy the demo out So you'll know which is what is what? Because of the labels so the death star is going to be the Empire org and it's going to be a death star class The Imperial tie fighters also in the same org So it's an Empire organization and it's going to be a different class as tie fire And then the X-Wing is the Alliance organization And the class of course is X-Wing So the deployment will also have a death star service what we just talked about and that's going to load balance all the traffic to all of the pods with the label org equals Empire and Death Star class, so let's install everything. There's a manifest in the background YAML And we are going to install so All of our objects are and are created. Let's see that everything's actually deployed the way that it should be I Can't type See this is why I don't type stuff. I Bet if I copied it works Well, that was just rude. There we go. All right, so At this point is already saying running But each part of go through several states until it reaches running at the point that pod is ready. So let's try it again Well, if you need to try it again until you see that everything has a running status Each part will also be represented represented in Sillium as an endpoint. So we want to see a list of all the endpoints that are managed by Sillium the Sillium endpoint or CEP CEP Resource can also be used. I will tell you now. I tried to manually type in and it did not work earlier So you might want to copy and paste this one and I promise I actually typed it correctly and it did that earlier Yeah It does work the second time. Thank you because that happened to me earlier and I was like who hates me All right, let's try it again. I had the same to this morning. Yeah, okay. I think there's a small delay. Thank you for that I appreciate it All right, so as you can see we've got our demo app installed and so let's go check on to our first test Yeah, before you do that notice the identities as well, right? So you can see The DevStar have similar labels because it's two pods So they have the same identity being allocated to the DevStar So that's under the roof Sillium providing a unique identity for similar workloads. So with this command you can actually Point and troubleshoot that did you all hear him over on that side? Kind of okay. Cool. All right, so let's go launch our first test So let's talk about DevStar access from the perspective of the DevStar service only the ships with the label Org equals Empire or anything that's an Empire org are allowed to connect and request a landing We don't have any rules in for it. So like what will happen if not only the tie fighter, but also the X-Wing request Landing so let's find out so Instead of actually running the full connectivity tests. We're gonna be using Curl to execute some API calls So let's see if we can land our tie fighter on the DevStar by running the following command Shift landed All right So the command above get let's us get a shell on the tie fighter pod and run an HTTP post request to the DevStar service to request Landing the command should work because the tie fighter and DevStar are all on the same side of you know the war Also known as the bad guys, which I hate because I'm a Boba Fett person, but anyway Now test if we can land the X-Wing the good guys. What do you all think's gonna happen? It's gonna work. All right, so let's see And you are correct So that's good for the rebels because they can get where they technically shouldn't be But unfettered access to the DevStar Is not great for them So Apparently a security policy is missing So let's here's a brief blurb about identities and cloud native IP Addresses are no longer relevant for cloud native workloads because security policies need something else. They just do Silly provides this so I'm uses the labels of science of the pots to define the security policies We're gonna start with a basic policy Restricting the DevStar landing requests you only the shifts that have the label or give us empire This should block or this blocks any shifts without the label to even connect to the DevStar service It's a simple policy that I'm not even say simple policy It's a policy that filters only on network layer three So that's the IP protocol and network layer four, which is a TCP protocol So it's often referred to as an L3 oh for network security policy And so this is what it looks like It has a graphic So let's go do some more stuff All right So the first thing first we're gonna start with that policy to restrict that star landing requests to the ships that only have The label or equals empire before we start changing policies right away Let's think about what that looks like or should look like I should say I'm gonna expand this just a little bit. Come on mouse. You like me today, right? There we go. So we need to match on Empire ships only so that label is what we need to match on And that's what that would look like Match labels or Empire class that star We also have to make sure that ingress from the endpoints with the label Empire are also allowed to port 80 for protocol TCP We see that in the image So while this example is relatively simple Operators sometimes find it difficult to understand and to build network policies And silly me has a solution for this So if you look at the top where you see terminal right next to that you will see the network policy editor What I will say is if you aren't something that has a size a MacBook Air-sized screen you are going to need to collapse Right here, you're gonna use that to collapse so you can actually see the visualization or else it won't show up Don't ask me how I know Thought some of those wrong earlier So I'm going to go through this blurb first and then just show you what the Netpol editor looks like So you can all click on that while I'm reading through this So click on it to see a visual and interactive representation of your policy and change some of the values if you want to play around It's better understand what the policy is doing and I'm going to be completely honest with you Networking has never been my forte. I used to cry for Cisco stuff like it just hasn't break fixes my thing The one thing I did like when I started using Silium or starting learning Silium because honestly I'm still learning is this editor that you all are looking at because it was easier for me to follow along with What everything was going on? Some people are visual and I just happen to be one of those people So the central part of the diagram represents the network policy selector and then each side will show Respectively which ingress and egress are allowed for the workload. So you basically want to verify that your current selector Which are the org equals empire class equals that star only allowed ingress track from pods label as org equals empire And that's what that would look like You can also check the corresponding network policy manifest in the editor below and note You can either use the Silium network policy or you can use the kubernetes network policy The other thing is if you're ever at home and you want to use something like this without having to spend a lot of Things up we do have editor Silium.io and I'm going to click on that before I actually show you the one in instruct because it's very very Easy to use and I talk about it all the time. So you'll get this most times Whenever you get on here, but this is what this looks like I'm not sure you would want to do try to do it from a mobile device But outside of that it's very very helpful and whenever you have the policy you want You can actually download it or just copy and paste it into your Yamaha All right, so this is what it looks like on the tutorial side This is basically the same thing. I just showed you it just doesn't have anything preloaded and that's that All right, so Let's enforce the policy and we're going to do that actually using the terminal So you might want to go back to the terminal tab And we can apply the pre-configured network policy with the values that we just talked about for the demo system So let's copy and paste that it'll let you know that it was created and let's try to land the Empire TIE fighter again To the Death Star Which she'll still which should still work Ship is landed now if you try to request a landing with your X-Wing However, you should see that it's gonna hang like nothing at all should happen at this point And if we still got ships landing that means I probably copy and pasted something incorrectly And as you see nothing is happening happening So that means that our rule actually did what it was supposed to do to get out of that control C So we blocked the access to the Death Star from X-Wing So let's see if we can make it a bit more fine grain that those of you that work in government separation of duties That's basically what we're about to do Or any other place similar All right, so it was sufficient to give either the TIE fighter X-Wing full access to Death Stars API or no access at all But are you absolutely sure that you can trust all of the TIE fighter pilots of the entire Empire? You're not because you don't know all of them if you do we got bigger problems We must provide the strongest security so enforce lease privilege Between microservices in each service that calls the Death Stars API should be limited to making only the set of HTTP requests It requires for legitimate operation So we just need to fill through the actual HTTP request and that's what this will look like So let's go do that All right, so think about this the Death Star service exposes some maintenance API's which should not be called by random Empire ships to see why those API's are sensitive We're gonna run this cube cuddle. Yes cuddle Say it again. We're gonna run this cube cuddle. Don't shake your head at me Command and the very first thing you see is there's a panic because the Death Star exploded This is why some things should not be touched by everyone. All right, so This is an illustrative example and yet it's kind of dramatic But unauthorized access such as above can have adverse security repercussions things can blow up So we need to enforce the policies on the HTTP layer which is layer seven to limit what exact API's The typewriter is allowed to call and which ones they aren't So we're gonna extend the existing policy with an HTTP rule that looks like this and That should restrict the API access to only The landing path and thus prevent users from accessing the exhaust port which is why we had something blow up a little while ago So again We're gonna go back to the network policy tab and It should be pre-filled. I'm just gonna show the image because you all know how to get there at this point But you want to verify that the policy will filter access to the Death Star by its path All right, so now let's enforce it. So we're back in the terminal and We are going to apply the updated policy Hey, hey, I said apply. Oh Now you're just being being hold on please There we go What am I copied a paste a copy of blank space? That's what I did Apologies, let me get that There we go, there we go It will let you know that's configured and then we're going to run the same test that we ran at the beginning And now you see access is denied, which is what we want it So with l7 security policies We're able to restrict the access only to the required API resources on Death Star and that may we that way We've implemented a least privilege security approach for the communication between the microservices And I think we're about to have another quiz Are we? I think yes All right, you all got me a last time. Let's see what happens this time All right. What's the first one? I need to check network policies can block or allow traffic between pods. Yes or no? All right L304 network policies can filter HTTP request Okay, we got some yups in the yeses L7 network policies can filter on HTTP paths Yes, okay, and the last one is psyllium supports standard kubernetes network policies All right, I got let's see what we got They could have just given us an all of the above, but you know ah One of these is wrong The second one. All right, let's try taking out the second one you get a gold star Thank you so much. Let's move on to the next part. We're almost through Actually, I think we are through so we saved the death star and we made the Empire safe place and I think you know what? We all deserve a gold star for that And some good coffee So let's let me hit this because I want to show you something So if you want to know more about psyllium and I think Ray has one more slide that he wanted to show you all We're helpful, which I really think is a really good UI if you go to The psyllium Website it'll give you a breakdown of what psyllium is It's going to give you a link to our slack Our slack is huge But everyone in there is exceptionally helpful, especially to beginners. I still ask beginner questions all the time But the other thing is if you want to contribute if you want to see the documentation Or if you want to know how to install on cake like cake 3s for example, or like I use my desktop it also has Instructions to do that also So please go check it out. And if you have any questions, you are free to tweet me and I'm gonna let Ray come back up Thank you. Thank you and as a bonus anyone completing the challenge We are working on some badges the correctly digital badges. So as soon they become available You will award it that batch for this lab as well, but be patient with us. We need some work to do there to make it work So, yeah, thank you Tracy. Thank you for running the lab. I hope you all liked it Please provide feedback to us if you want to know more and there are I think already 10 labs we provide Both open source and enterprise labs on different topics also cluster mesh egress gateway things like BGP and advanced networking So let me plug in my No, it's fine So besides slack we have on this conference two booths, we have a psyllium booth. We have an isovalent booth Feel free to to visit us if you want to know more about ebpf we provide you keep the option or the Opportunity I would say to get the what is ebpf book signed by Liz and we also have Natalia who has the security Advanced ebpf book. So if you want to know really more about that technology, how it actually work I recommend to visit it as us at the booth and even get it signed by Liz For enterprise solutions go to isovalent.com to know more about that and that concludes this session Thank you, Tracy. Thank you Duffy for helping out. I hope you liked it. Enjoy kube.com and thanks for joining Good good points Answer questions. No, all right. Okay. Oh wait. You got one. Oh You want to see Hubble Hubble. Yeah, this is Hubble UI Didn't I just shared it or did you join a bit later? Is there something specific you want to see? Oh Wait, did you want to see the CLR? Did you want to see the UI? Yeah, okay. Yeah, yeah, so so to to give it a bit more so on the left here on the top You can select namespaces to monitor so I can also monitor kube system if I like But let's go back to the app example So basically the top section allows you to filter either by selecting components and services or Entering a filter you can filter on verdicts dropped forwarded and such The top section shows live flows and if you click on a specific Service it will focus the view for that given service and it will focus all the flows as well Ingress and egress from that given service Does that help? Good welcome another question. It's the actual traffic doesn't matter if it's allowed or denied We can already using ebpf observe flows between them between services so if I would have a Deny policy or not allowing specific traffic you would see drops Continuing in the flows Appearing and if it's allowed it will just forward and show it as well. You have to have traffic. Yeah, that's that's the case We yeah, you have to have traffic to have Hubble observe that traffic Welcome Any other question? Yes, please. I'm no not on on on that layer for the WT So with sidecar you mean you service measure mean yeah, so so authorization Authentication is coming in Cillium 1.13. So that's a roadmap implementation Any other question? Cool. Thank you for again for joining us. Enjoy your day