what's up guys and girls raj here back with another video in this video we are going to learn about kubernetes network policy this is one of those things which seem complicated but we are going to understand it in a simple manner as well as see it in action with a demo alright let's get started let's start with kubernetes pod networking requirements each pod gets its own ip address all pods can communicate with other parts without any network address translation and what this means is the ip address of the pod is same throughout the cluster so if you have two namespaces in your cluster namespace1 and namespace2 and you have some pods running in each of those namespaces so one part from namespace1 can ping the other part in namespace 2 using the ip address directly it doesn't need to translate the address and it doesn't matter whether these two parts are running in two different worker nodes throughout the whole cluster the pods will have the same ip address so expanding this to a more real-world scenario let's say in your kubernetes cluster you have two applications running in two different name spaces app a and app b you also have a namespace for database where you are running some pods for your redis database remember by default all the communication between all these pods are allowed so both the pods for app a and app b will be able to reach the pods running in namespace database but what if in a multi-tenant cluster you want to be specific so you want the pods running in app a communicate with the database but you don't want the pods for application b or app b namespace communicate with the same database so this is what you achieve using kubernetes network policies using network policies you can control traffic flow at the ip address or port level which is osi layer 3 r4 in between these pods so this is great for multi-tenant cluster where in the same cluster you are running multiple applications or you or you are sharing the same cluster for development test and production so let's jump into the demo so i have a eks cluster running and if i run cube ctl get pods dash a which is gonna show us all the parts running in my cluster so you can see there are three namespaces namespace a namespace b and namespace c that i created outside of the default namespaces and you can see there is one part running in each namespace so if i run the command keepctl getpods dash a dash o space white this is gonna show us the ip address of the pods for each part running within namespace a b and c we have the ip addresses so let's try to ping these parts from each other so let's say we want to ping the pod running in namespace b from the pod running in namespace a so the command we will run is cubectl dash n for namespace namespace dash a and then this exec part means whatever command we're gonna put at the end will be executed from inside this pod so it will be executed from inside the pod this test eight four five five dash qvqfn which is the name of the pod in namespace a and what is the command it is going to execute it is going to execute the command at the end which is call and then an ip address this ip address is actually the ip address of the pod running in namespace b so basically we are trying to reach to the pod running in namespace b from the pod running in namespace a and as you can see from the output it gets a response back all these pods are running engine x container so it gets the standard engine x response similarly we can ping the same part running in namespace b from namespace c so the pod ending with h4 vdw is actually the name of the pod running in namespace c and the ip address is same which is the pod running in namespace b so if we map this out in our previous diagram so we have three namespaces namespace a b and c and now i have put the actual pod in each of them with the actual ip addresses that we got from running our cube ctrl commands i have also shown the label for namespace a which is myspace colon namespace a and the label for the pod running in namespace b which is environment colon test so the objective of kubernetes network policy will be namespace b pod should be allowing traffic from namespace a but the traffic from namespace c should not be allowed and this is the command to see the labels for namespace so i'm running cube ctrl describe namespace space namespace dash a and you can see the label is myspace equals to namespace a so what will be the network policy so this is the actual network policy the kind network policy signifies that this is a manifest for network policy under metadata name is just the name for this network policy but more importantly the namespace namespace dash b and under spec the part selector with match level environment colon test signifies that this network policy is implemented for the pods with the label environment colon test within the namespace namespace dash b under policy types you have two options ingress is to control the incoming traffic into this pod you can also have egress which controls the outgoing traffic from this pod but in this case we are only controlling the incoming traffic so that's why the policy type only contains ingress now under ingress under the from statement we are specifying the clause name space selector so this network policy only allowed traffic coming from the pods running in a namespace with a label myspace colon namespace a which is in this case namespace dash a and after you deploy this network policy this part in namespace b will not accept traffic from any other part which doesn't match this ingress criteria so the pods running within namespace c should not be able to communicate with the parts in namespace b once you have this network policy emal file you apply it like you apply any manifest which is cubectl apply dash f and then the name of the network policy file so if you don't do anything else and you applied this policy and then you try to ping namespace b pod with the ip address 192.168.1.66 from namespace c it should not have been allowed right because that's what this network policy should be doing but you can see the curl goes through so why is this not working because network policies requires network policy agents to be effective network policy agents enforces the network policies and network policy agents are not installed automatically in your kubernetes cluster so there are some options for you to install different network policies we have we works calico andrea etc so for this case we are going to install calico which is the open source network policy in our eks cluster so this is the link to install calico uniques cluster it's pretty straightforward doing couple of cube ctl applies so let's go ahead and install calico in our cluster all right so let's install calico so i'm going to copy these commands paste it here all right so the calico is installed all right now that calico is installed in our cluster let's test out if this works so now we are going to call from namespace a pod to namespace b pod and this should be allowed as per the network policy okay so we are calling namespace a to namespace b pod ip address nice so this is working now the moment of truth now let's try to call from namespace c pod to the same namespace b part and this time it should fail all right here we go from namespace c pod to namespace b part ip address and as you can see we did not get any response back it is still hanging and that means our network policy along with calico is working there are a couple of other options to restrict traffic so we learned about restricting traffic using namespace you can also restrict or allow traffic using ip address block and also using the labels in the pod so on the network policy on the left mention there is a dash in front of all these selectors that means these conditions are working we as are so whenever one of this condition is true for the incoming traffic the traffic will go through in contrast on the network policy document on the right you will see there are no dash in front of namespace selector or the pod selector so these are working as and condition all these three conditions needs to be satisfied for the traffic to go in so these are the two main ways that you will use network policies but beyond that you can also use port in ingress and egress so let's take a look from the kubernetes documentation so in this sample network policy under policy types you can see we have dash egress in addition to dash ingress so under ingress one thing to note is it's also controlling traffic in a specific port so not only it has to match one of these conditions for the incoming traffic but the incoming traffic should be coming within this port else it will not be allowed and under egress this controls the outgoing traffic so this 2 and then ip block cidr means any pod where you are applying this network policy to in this case the pods within the default namespace with the role db will only be able to connect or reach out to the pods within the ip address of this cidr block and the outgoing connecting traffic should be directed to the port 5978 note that whatever traffic is allowed by the ingress rule and coming to the pod is allowed to go back out that is not controlled by this egress rule this egress rule only applies for the connection initiated from this pod where this network policy is being applied to i have saved the sample network policy that i covered in this demo in my github repository so feel free to grab it and test it out just a little plug if you are interested in learning kubernetes and container with amazon eks fargate with devops feel free to check out my udemy course it has pretty high rating and some very good reviews it starts with simple container concepts and then goes to basic kubernetes then to advanced kubernetes and then dives deep into eks concepts and then how to implement applications on kubernetes using devops alright guys and girls that's the video if you found this video helpful if you learned something new from this video please click that like button smash it if that's something you are into each like really helps this channel girl youtube algorithm recommends this video to other viewers when you click the like button also click subscribe if you are not subscribed uh ask me any questions in the comment section let me know what other kubernetes videos you want me to make all right guys and girls that's it for this video i'll see you in the next one bye