1 00:00:02,810 --> 00:00:06,710 Hello and welcome to this lecture on network policies. 2 00:00:06,710 --> 00:00:10,960 So let us first get our networking and security basics right. 3 00:00:11,160 --> 00: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 4 00:00:17,450 --> 00:00:18,380 on the same page. 5 00:00:18,380 --> 00:00:26,230 Before we begin we will start with a simple example of a traffic flowing through a web app and database 6 00:00:26,230 --> 00:00:34,720 server so you have a web server serving front-end to users an app server serving back-end API and 7 00:00:34,720 --> 00:00:36,160 a database server. 8 00:00:36,450 --> 00: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 9 00:00:43,090 --> 00:00:46,060 server at port 5000 in the back end. 10 00:00:46,270 --> 00:00:54,280 The API server then fetches data from the database server at Port 3306 and then sends the data back 11 00:00:54,280 --> 00:00:55,450 to the user. 12 00:00:55,580 --> 00:01:03,170 A very simple setup so there are two types of traffic here ingress and egress. 13 00:01:03,340 --> 00:01:10,930 For example for a web server the incoming traffic from the users is an ingress traffic and the outgoing 14 00:01:10,930 --> 00:01:17,980 request to the app server is a egress traffic and that is denoted by the straight arrow. 15 00:01:17,980 --> 00:01:24,310 When you define ingress and egress remember you're only looking at the direction in which the traffic 16 00:01:24,430 --> 00:01:25,790 originated. 17 00:01:25,930 --> 00:01:32,410 The response back to the user denoted by the dotted lines do not really matter. 18 00:01:32,410 --> 00:01:39,280 Similarly in case of the back end API server it receives ingress traffic from the web server on port 19 00:01:39,320 --> 00:01:47,470 5000 and has egress traffic to port 3306 to the database server and from the database 20 00:01:47,470 --> 00:01:55,040 servers perspective it receives ingress traffic on 3306 from the API server. 21 00:01:55,270 --> 00:02:02,290 If we were to list the rules required to get this working we would have an ingress rule that is required 22 00:02:02,350 --> 00:02:10,180 to accept HTTP traffic on port 80 on the web server. An Egress rule to allow traffic from the web server 23 00:02:10,450 --> 00:02:19,750 to port 5000 on the API server. An ingress rule to accept traffic on port 5000 on the API server and 24 00:02:19,750 --> 00:02:25,610 an egress rule to allow traffic to port 3306 on the database server. 25 00:02:25,810 --> 00:02:32,320 . And finally an ingress rule on the database server to accept traffic on port 3306. 26 00:02:32,860 --> 00:02:37,000 So that's the basic of traffic flow and rules. 27 00:02:37,000 --> 00:02:40,700 Let us now look at Network Security in Kubernetes. 28 00:02:40,900 --> 00:02:46,420 So we have a cluster with a set of nodes hosting a set of pods and services. 29 00:02:46,870 --> 00: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 30 00:02:54,910 --> 00:03:01,630 in kubernetes, is whatever solution you implement, the pods should be able to communicate with 31 00:03:01,630 --> 00:03:06,830 each other without having to configure any additional settings like routes. 32 00:03:07,030 --> 00:03:14,530 For example, in this network solution, all pods are on a virtual private network that spans across 33 00:03:14,530 --> 00:03:21,850 the nodes in the kubernetes cluster. And they can all by default reach each other using the IPs 34 00:03:21,970 --> 00:03:26,620 or pod names or services configured for that purpose. 35 00:03:26,620 --> 00:03:35,440 Kubernetes is configured by default with an “All Allow” rule that allows traffic from any pod to any other 36 00:03:35,440 --> 00:03:43,850 pod or services. Let us now bring back our earlier discussion and see how it fits 37 00:03:43,940 --> 00:03:51,800 in to kubernetes. For each component in the application we deploy a POD. One for the front-end web server, 38 00:03:52,250 --> 00:03:55,940 for the API server and one for the database. 39 00:03:55,940 --> 00:04:03,230 We create services to enable communication between the PODs as well as to the end user. Based on what 40 00:04:03,230 --> 00:04:10,280 we discussed in the previous slide, by default all the three PODs can communicate with each other within 41 00:04:10,280 --> 00:04:17,680 the kubernetes cluster. What if we do not want the front-end web server to be able to communicate with 42 00:04:17,680 --> 00:04:25,180 the database server directly say for example your security teams and audits require you to prevent that 43 00:04:25,180 --> 00:04:26,710 from happening. 44 00:04:26,800 --> 00:04:34,000 That is where you would implement a Network Policy to allow traffic to the db server only from the api 45 00:04:34,000 --> 00:04:39,670 server. A Network policy is another object in the kubernetes namespace. 46 00:04:39,790 --> 00:04:43,180 Just like PODs, ReplicaSets or Services. 47 00:04:43,450 --> 00:04:47,410 You link a network policy to one or more pods. 48 00:04:47,620 --> 00:04:50,600 You can define rules within the network policy. 49 00:04:50,710 --> 00:04:59,100 In this case I would say, only allow Ingress Traffic from the API Pod on Port 3306. 50 00:04:59,170 --> 00:05:07,240 Once this policy is created, it blocks all other traffic to the Pod and only allows traffic that matches 51 00:05:07,240 --> 00:05:09,390 the specified rule. 52 00:05:09,640 --> 00:05:15,060 Again, this is only applicable to the Pod on which the network policy is applied. 53 00:05:16,640 --> 00:05:21,050 So how do you apply or link a network policy to a pod. 54 00:05:21,050 --> 00:05:28,730 We use the same technique that was used before to link ReplicaSets or Services to Pods. Labels and Selectors. 55 00:05:29,360 --> 00:05:37,220 We label the Pod and use the same labels on the pod selector field in the network policy. And then 56 00:05:37,280 --> 00:05:44,630 we build our rule under policy types specify whether the rule is to allow ingress or egress traffic 57 00:05:44,990 --> 00:05:45,980 or both. 58 00:05:46,220 --> 00:05:52,440 In our case we only want to allow ingress traffic to the db-pod. So we add Ingress. 59 00:05:52,670 --> 00:06:01,550 Next, we specify the ingress rule, that allows traffic from the API pod. And you specify the api pod, again 60 00:06:01,640 --> 00:06:03,640 using labels and selectors. 61 00:06:03,830 --> 00:06:09,080 And finally the port to allow traffic on, which is 3306. 62 00:06:09,200 --> 00:06:11,150 Let us put all that together. 63 00:06:11,210 --> 00:06:17,540 We start with a blank object definition file and as usual we have apiVersion, kind, 64 00:06:17,540 --> 00:06:25,280 metadata and spec. The apiVersion is networking.k8s.io/v1, 65 00:06:25,540 --> 00:06:33,500 the kind is NetworkPolicy. We will name the policy db-policy. And then under the spec section, 66 00:06:33,650 --> 00:06:41,210 we will first move the pod selector to apply this policy to the db pod. Then we will move the rule 67 00:06:41,240 --> 00:06:45,520 we created in the previous slide under it and that's it. 68 00:06:45,590 --> 00:06:54,080 We have our first network policy ready. Run the kubectl create command to create the policy. Remember 69 00:06:54,140 --> 00:07:01,190 that Network Policies are enforced by the Network Solution implemented on the Kubernetes Cluster. And not 70 00:07:01,250 --> 00:07:05,160 all network solutions support network policies. 71 00:07:05,330 --> 00:07:12,360 A few of them that are supported are kube-router, Calico, Romana and Weave-net. 72 00:07:12,740 --> 00:07:18,170 If you used Flannel as the networking solution, it does not support network policies 73 00:07:18,170 --> 00:07:24,230 as of this recording. Always refer to the network solution’s documentation to see support for network 74 00:07:24,230 --> 00:07:25,640 policies. 75 00:07:25,640 --> 00:07:32,180 Also remember even in a cluster configured with a solution that does not support network policies you 76 00:07:32,180 --> 00:07:36,690 can still create the policies but they will just not be enforced. 77 00:07:36,800 --> 00:07:43,100 You will not get an error message saying the network solution does not support network policies. 78 00:07:43,100 --> 00:07:48,860 Well, that’s it for this lecture. Walk through the documentation and head over to coding challenges 79 00:07:49,040 --> 00:07:50,840 to practice network policies.