WEBVTT 00:02.810 --> 00:06.710 Hello and welcome to this lecture on network policies. 00:06.710 --> 00:10.960 So let us first get our networking and security basics right. 00:11.160 --> 00:17.450 And I'm sorry if this is too basic but I just wanted to spend a minute on this to make sure we are all 00:17.450 --> 00:18.380 on the same page. 00:18.380 --> 00:26.230 Before we begin we will start with a simple example of a traffic flowing through a web app and database 00:26.230 --> 00:34.720 server so you have a web server serving front-end to users an app server serving back-end API and 00:34.720 --> 00:36.160 a database server. 00:36.450 --> 00:43.090 The user sent in a request to the web server at port 80 the web server then sent a request to the API 00:43.090 --> 00:46.060 server at port 5000 in the back end. 00:46.270 --> 00:54.280 The API server then fetches data from the database server at Port 3306 and then sends the data back 00:54.280 --> 00:55.450 to the user. 00:55.580 --> 01:03.170 A very simple setup so there are two types of traffic here ingress and egress. 01:03.340 --> 01:10.930 For example for a web server the incoming traffic from the users is an ingress traffic and the outgoing 01:10.930 --> 01:17.980 request to the app server is a egress traffic and that is denoted by the straight arrow. 01:17.980 --> 01:24.310 When you define ingress and egress remember you're only looking at the direction in which the traffic 01:24.430 --> 01:25.790 originated. 01:25.930 --> 01:32.410 The response back to the user denoted by the dotted lines do not really matter. 01:32.410 --> 01:39.280 Similarly in case of the back end API server it receives ingress traffic from the web server on port 01:39.320 --> 01:47.470 5000 and has egress traffic to port 3306 to the database server and from the database 01:47.470 --> 01:55.040 servers perspective it receives ingress traffic on 3306 from the API server. 01:55.270 --> 02:02.290 If we were to list the rules required to get this working we would have an ingress rule that is required 02:02.350 --> 02:10.180 to accept HTTP traffic on port 80 on the web server. An Egress rule to allow traffic from the web server 02:10.450 --> 02:19.750 to port 5000 on the API server. An ingress rule to accept traffic on port 5000 on the API server and 02:19.750 --> 02:25.610 an egress rule to allow traffic to port 3306 on the database server. 02:25.810 --> 02:32.320 . And finally an ingress rule on the database server to accept traffic on port 3306. 02:32.860 --> 02:37.000 So that's the basic of traffic flow and rules. 02:37.000 --> 02:40.700 Let us now look at Network Security in Kubernetes. 02:40.900 --> 02:46.420 So we have a cluster with a set of nodes hosting a set of pods and services. 02:46.870 --> 02:54.910 Each node has an IP address and so does each pod as well as service. One of the pre-requisite for networking 02:54.910 --> 03:01.630 in kubernetes, is whatever solution you implement, the pods should be able to communicate with 03:01.630 --> 03:06.830 each other without having to configure any additional settings like routes. 03:07.030 --> 03:14.530 For example, in this network solution, all pods are on a virtual private network that spans across 03:14.530 --> 03:21.850 the nodes in the kubernetes cluster. And they can all by default reach each other using the IPs 03:21.970 --> 03:26.620 or pod names or services configured for that purpose. 03:26.620 --> 03:35.440 Kubernetes is configured by default with an “All Allow” rule that allows traffic from any pod to any other 03:35.440 --> 03:43.850 pod or services. Let us now bring back our earlier discussion and see how it fits 03:43.940 --> 03:51.800 in to kubernetes. For each component in the application we deploy a POD. One for the front-end web server, 03:52.250 --> 03:55.940 for the API server and one for the database. 03:55.940 --> 04:03.230 We create services to enable communication between the PODs as well as to the end user. Based on what 04:03.230 --> 04:10.280 we discussed in the previous slide, by default all the three PODs can communicate with each other within 04:10.280 --> 04:17.680 the kubernetes cluster. What if we do not want the front-end web server to be able to communicate with 04:17.680 --> 04:25.180 the database server directly say for example your security teams and audits require you to prevent that 04:25.180 --> 04:26.710 from happening. 04:26.800 --> 04:34.000 That is where you would implement a Network Policy to allow traffic to the db server only from the api 04:34.000 --> 04:39.670 server. A Network policy is another object in the kubernetes namespace. 04:39.790 --> 04:43.180 Just like PODs, ReplicaSets or Services. 04:43.450 --> 04:47.410 You link a network policy to one or more pods. 04:47.620 --> 04:50.600 You can define rules within the network policy. 04:50.710 --> 04:59.100 In this case I would say, only allow Ingress Traffic from the API Pod on Port 3306. 04:59.170 --> 05:07.240 Once this policy is created, it blocks all other traffic to the Pod and only allows traffic that matches 05:07.240 --> 05:09.390 the specified rule. 05:09.640 --> 05:15.060 Again, this is only applicable to the Pod on which the network policy is applied. 05:16.640 --> 05:21.050 So how do you apply or link a network policy to a pod. 05:21.050 --> 05:28.730 We use the same technique that was used before to link ReplicaSets or Services to Pods. Labels and Selectors. 05:29.360 --> 05:37.220 We label the Pod and use the same labels on the pod selector field in the network policy. And then 05:37.280 --> 05:44.630 we build our rule under policy types specify whether the rule is to allow ingress or egress traffic 05:44.990 --> 05:45.980 or both. 05:46.220 --> 05:52.440 In our case we only want to allow ingress traffic to the db-pod. So we add Ingress. 05:52.670 --> 06:01.550 Next, we specify the ingress rule, that allows traffic from the API pod. And you specify the api pod, again 06:01.640 --> 06:03.640 using labels and selectors. 06:03.830 --> 06:09.080 And finally the port to allow traffic on, which is 3306. 06:09.200 --> 06:11.150 Let us put all that together. 06:11.210 --> 06:17.540 We start with a blank object definition file and as usual we have apiVersion, kind, 06:17.540 --> 06:25.280 metadata and spec. The apiVersion is networking.k8s.io/v1, 06:25.540 --> 06:33.500 the kind is NetworkPolicy. We will name the policy db-policy. And then under the spec section, 06:33.650 --> 06:41.210 we will first move the pod selector to apply this policy to the db pod. Then we will move the rule 06:41.240 --> 06:45.520 we created in the previous slide under it and that's it. 06:45.590 --> 06:54.080 We have our first network policy ready. Run the kubectl create command to create the policy. Remember 06:54.140 --> 07:01.190 that Network Policies are enforced by the Network Solution implemented on the Kubernetes Cluster. And not 07:01.250 --> 07:05.160 all network solutions support network policies. 07:05.330 --> 07:12.360 A few of them that are supported are kube-router, Calico, Romana and Weave-net. 07:12.740 --> 07:18.170 If you used Flannel as the networking solution, it does not support network policies 07:18.170 --> 07:24.230 as of this recording. Always refer to the network solution’s documentation to see support for network 07:24.230 --> 07:25.640 policies. 07:25.640 --> 07:32.180 Also remember even in a cluster configured with a solution that does not support network policies you 07:32.180 --> 07:36.690 can still create the policies but they will just not be enforced. 07:36.800 --> 07:43.100 You will not get an error message saying the network solution does not support network policies. 07:43.100 --> 07:48.860 Well, that’s it for this lecture. Walk through the documentation and head over to coding challenges 07:49.040 --> 07:50.840 to practice network policies.