- [Instructor] Okay welcome back. If you recall, when we first provisioned our Minikube hosted Kubernetes cluster, we set it up to use CNI, and in particular the Cilium CNI implementation. 

In this lecture we're going to create the following Kubernetes resources, which will be created to provide networking ingress controls. We'll create a default deny all networking policy, followed by a Mongo to Mongo allow all networking policy, and finally an API to Mongo allow all networking policy. With these networking policies in place, we can control and authorize the networking traffic sent between pods. The Cilium CNI plugin supports creating networking policies to find either using layer 4 and or layer 7 based rules. 

In this demonstration we'll only be using layer 4 rules, or more clearly our rules will white list all ingress network traffic based on pod label selectors. I'll explain this in more detail towards the end of the lecture. Okay, to start with, let's jump into the voteapp Kubernetes directory, and again display the contents using the tree command. We'll first apply the default deny all network policy. This will prevent all pod to pod network traffic but only within the cloud academy name space. And, which is the name space where all of our application pods exist. When we do this, the application will cease to function properly until we add in the remaining networking policies. Okay let's begin. I'll run the following command: kubectl apply dash F, and I'll give it the default deny all policy. As just mentioned applying this policy, breaks the application for various reasons. 

To see this first hand, let's jump back into the browser and reload the application, and as expected the application is unable to render the programming details for each language. Why is this so? Let's now reopen developer tools, and again filter on the ajax generator traffic for the initial page load. Here we can see clearly that all 3 ajax requests are in a pending state, and no response has been returned immediately. This is directly related to our default deny all network policy that we just applied within the could academy name space. 

Okay, let's now fix the application by applying all of the networking policies contained within the netpole directory. I'll run the command: kubectl apply dash F and pass in the netpole directory name. Right, if we now retest from within the browser it should all work again, as it does. This indicates that we are now successfully controlling traffic between pods within our cloud academy name space. This is an extremely useful security feature that should be used when working not just with multi-tenanted clusters, but when you need to vet the traffic between pods within a single name space or across name spaces. 

Now before we finish, let's take a closer look at each of the 3 networking policies that we just applied. I'll first clear the terminal. Next I'll use the vim editor and open the default deny all policy like so. Here we can see that it has an empty pod selector, and a policy type of ingress only. This creates a default isolation policy in the cloud academy name space, by selecting all pods and not allowing any ingress traffic to those pods. Note, this policy does not change the default egress behavior. 

Okay let's now close this policy and next I'll open the Mongo to Mongo allow policy. Here we can see that the pod selector matches on role equal to DB, and that the ingress pod selector also matches on role equal to DB. This creates our policy which allows the 3 Mongo replicas to talk to each other, which is a requirement for replicating the data amongst themselves.

And finally, I'll open the API to Mongo allow policy. Here we can see that the pod selector matches on role equal to DB, and that the ingress pod selector matches on role equal to API. This creates our policy which allows ingress traffic sent from the API pods, into the Mongo DB replica pods. Now, you may be wondering why there isn't a network policy explicitly put aside to control traffic from the front end pods into the API pods. Well, actually the front end pods don't communicate directly with the API pods, remembering that it is the browser which is making ajax requests to the API pods, through the Nginx Ingress Controller. 

Okay, that completes this lecture. Our networking security posture has been strengthened, this is a bonus. Let's now move on and provide some useful troubleshooting tips when creating and deploying networking policies.