1 00:00:00,180 --> 00:00:04,950 In this lecture, we will take a look at network policies in more detail. 2 00:00:06,050 --> 00:00:12,080 So here we have the same Web API and database parts that we discussed about in the previous lecture. 3 00:00:12,860 --> 00:00:16,010 So first, let's be very clear with our requirements. 4 00:00:16,460 --> 00:00:23,780 Our goal is to protect the database part so that it does not allow access from any other part except 5 00:00:23,780 --> 00:00:27,970 the API part and only on PT. three three zero six. 6 00:00:28,580 --> 00:00:34,120 So let's assume that we are not concerned about the Web or the API part for those parts. 7 00:00:34,130 --> 00:00:37,820 We are OK for all traffic to go in and out from anywhere. 8 00:00:38,330 --> 00:00:44,650 However, we want to protect the database part and only allow traffic from the API part. 9 00:00:45,290 --> 00:00:50,960 So let's get the other things out of our way so we can focus exactly on the required tasks. 10 00:00:51,350 --> 00:00:58,100 So we don't need to worry about the Web pod on its support as we don't want to allow any traffic from 11 00:00:58,100 --> 00:01:00,850 any other sources other than the API part. 12 00:01:00,860 --> 00:01:03,230 So let's get rid of that. 13 00:01:03,800 --> 00:01:10,190 We can also forget about the port on the API part to which the Web server connects as we don't care 14 00:01:10,190 --> 00:01:11,030 about that either. 15 00:01:11,950 --> 00:01:19,120 As we discussed by default, cabernets allows all traffic from all parts to all destinations, so as 16 00:01:19,120 --> 00:01:24,850 the first step, we want to block out everything going in and out of the database part. 17 00:01:25,630 --> 00:01:27,550 So we create a network policy. 18 00:01:27,910 --> 00:01:30,280 We will call it DB policy. 19 00:01:30,280 --> 00:01:35,980 And the first step is to associate this network policy with the part that we want to protect. 20 00:01:36,400 --> 00:01:38,980 And we do that using labels and selectors. 21 00:01:39,530 --> 00:01:47,170 So we do that by adding a part selector field with the match labels option and by specifying the label 22 00:01:47,170 --> 00:01:51,610 on the DB part, which happens to be set to roll to be. 23 00:01:52,790 --> 00:01:59,900 And that associates the network policy with the database pod and blocked out all traffic, however, 24 00:02:00,260 --> 00:02:05,900 we need the API part to be able to carry the database on four three three zero six. 25 00:02:05,900 --> 00:02:08,230 So that's what we are going to configure next. 26 00:02:08,990 --> 00:02:15,050 First, we need to figure out what type of policies should be defined on this network policy object 27 00:02:15,050 --> 00:02:16,570 to meet our requirements. 28 00:02:17,390 --> 00:02:21,230 So there are two types of policies that we discussed in the previous lecture. 29 00:02:21,560 --> 00:02:23,750 We have ingress and egress. 30 00:02:24,410 --> 00:02:27,560 So do we need ingress or egress here or both? 31 00:02:28,670 --> 00:02:35,540 So you always look at this from the deep parts perspective, from the DB parts perspective, we want 32 00:02:35,540 --> 00:02:38,900 to allow incoming traffic from the API part. 33 00:02:39,320 --> 00:02:40,490 So that is incoming. 34 00:02:40,520 --> 00:02:42,020 So that is ingress. 35 00:02:42,620 --> 00:02:49,550 The API part makes database queries and the database pods returns the results. 36 00:02:50,390 --> 00:02:52,280 So what about the results? 37 00:02:53,090 --> 00:02:58,900 Do you need a separate rule for the results to go back to the airport? 38 00:03:00,680 --> 00:03:08,330 No, because once you allow incoming traffic, the response or reply to that traffic is allowed back 39 00:03:08,330 --> 00:03:09,230 automatically. 40 00:03:09,380 --> 00:03:11,520 We don't need a separate rule for that. 41 00:03:11,930 --> 00:03:18,290 So in this case, all we need is an increased rule to allow traffic from the airport to the database 42 00:03:18,290 --> 00:03:24,620 part, and that would allow the airport to connect to the database and run queries and also retrieve 43 00:03:24,620 --> 00:03:25,890 the result of the queries. 44 00:03:26,510 --> 00:03:32,810 So when deciding on what type of rule is to be created, you only need to be concerned about the direction 45 00:03:32,810 --> 00:03:37,700 in which the request originates and which is denoted by the straight line here. 46 00:03:37,970 --> 00:03:42,980 And you don't need to worry about the response, which is denoted by the dotted line. 47 00:03:43,670 --> 00:03:50,810 However, this rule does not mean that the database part will be able to connect to the airport or make 48 00:03:50,810 --> 00:03:52,130 calls to the API. 49 00:03:53,100 --> 00:03:59,700 See, for example, the database pod tries to make an API call to the API pod, then that would not 50 00:03:59,700 --> 00:04:05,130 be allowed because that is now an egress traffic originating from the database pod and would require 51 00:04:05,400 --> 00:04:08,020 a specific egress rule to be defined. 52 00:04:08,730 --> 00:04:15,140 So I hope you get the difference between the two and are clear about ingress and egress rules. 53 00:04:16,220 --> 00:04:21,810 I just wanted to make sure that you're clear on what type of policy is to be selected for the requirement 54 00:04:21,960 --> 00:04:23,010 that you have in hand. 55 00:04:23,900 --> 00:04:29,930 So a single network policy can have an ingress type of role and egress type of rule or both in cases 56 00:04:29,930 --> 00:04:35,610 where a party wants to allow incoming connections as well as wants to make external calls. 57 00:04:36,320 --> 00:04:40,550 So for now, our use case only requires increased policy types. 58 00:04:41,270 --> 00:04:47,420 Now that we have decided on the type of policy, the next step is to define the specifics of that policy. 59 00:04:48,750 --> 00:04:56,310 If it's ingress, we create a section called Ingress within which we can specify multiple rules. 60 00:04:56,670 --> 00:05:03,360 Each rule has a from and ports feels the from field defines the source of traffic that is allowed to 61 00:05:03,360 --> 00:05:05,100 pass through to the database part. 62 00:05:05,610 --> 00:05:11,490 And here we would use a part selector and provide the labels of the API pod like this. 63 00:05:12,420 --> 00:05:17,770 The sports field defines what sport on the database part is, the traffic allowed to go to. 64 00:05:17,970 --> 00:05:23,440 In this case, it's three three zero six with the TCP protocol and that's it. 65 00:05:23,610 --> 00:05:30,270 This would create a policy that would block all traffic to the DB part except for traffic from the API 66 00:05:30,270 --> 00:05:30,660 part. 67 00:05:32,070 --> 00:05:38,040 Now, what if there are multiple airports in the cluster with the same labels, but in different name 68 00:05:38,040 --> 00:05:44,280 spaces, so say here we have different name spaces for dev test and prod environments, and we have 69 00:05:44,280 --> 00:05:47,750 the airport with the same labels in each of these environments. 70 00:05:48,360 --> 00:05:54,870 The current policy would allow any part in any namespace with matching labels to reach the database 71 00:05:54,880 --> 00:05:55,220 part. 72 00:05:55,470 --> 00:06:01,500 We only want to allow the API part in the namespace to reach the database part. 73 00:06:01,950 --> 00:06:02,970 So how do we do that? 74 00:06:03,480 --> 00:06:10,410 For this we add a new selector called as the namespace selector property and along with the selector 75 00:06:10,410 --> 00:06:10,950 property. 76 00:06:11,220 --> 00:06:17,490 Under this we use match labels again to provide a label set on the namespace. 77 00:06:17,910 --> 00:06:24,660 And you must remember that you must have this label set on the namespace first for this to work. 78 00:06:25,670 --> 00:06:31,430 So that's what the namespace selector does, it helps in defining from what namespace traffic is allowed 79 00:06:31,430 --> 00:06:33,110 to reach the database part. 80 00:06:34,620 --> 00:06:42,580 Now, what if you only have the name space selector and not the pod selector like this, in this case, 81 00:06:42,600 --> 00:06:49,380 all pods within the specified namespace will be allowed to reach the database pod, such as the Web 82 00:06:49,380 --> 00:06:50,640 part that we had earlier. 83 00:06:51,850 --> 00:06:56,230 But parts from outside this namespace won't be allowed to go through. 84 00:06:57,370 --> 00:07:03,970 Let's look at another use case, say we have a backup server somewhere outside of the cornetist cluster 85 00:07:04,390 --> 00:07:07,690 and we want to allow the server to connect to the database pod. 86 00:07:08,600 --> 00:07:14,950 Now, since this backup server is not deployed in our current cluster, the pod selector and namespace 87 00:07:14,960 --> 00:07:21,770 electric fields that we use to define traffic from won't work because it's not a part in the cluster. 88 00:07:22,850 --> 00:07:29,350 However, we know the IP address of the backup server, and that happens to be 190 to that 168 or five 89 00:07:29,420 --> 00:07:29,930 or 10. 90 00:07:31,240 --> 00:07:37,570 We could configure a network policy to allow traffic originating from certain IP addresses. 91 00:07:38,670 --> 00:07:46,050 For this, we add a new type of from definition known as the IP block definition IP block allows you 92 00:07:46,050 --> 00:07:51,820 to specify a range of IP addresses from which you could allow traffic to hit the database pod. 93 00:07:52,560 --> 00:07:59,540 So those are three separate selectors under the front section and ingress. 94 00:08:00,000 --> 00:08:03,560 And these are also applicable to the two section in egress. 95 00:08:03,780 --> 00:08:06,060 And we'll see that in a few minutes. 96 00:08:06,750 --> 00:08:10,140 We have pod selector to select pod by labels. 97 00:08:10,140 --> 00:08:16,110 We have namespace selector to select namespace by labels and we have the IP block selector to select 98 00:08:16,410 --> 00:08:17,670 IP address ranges. 99 00:08:18,480 --> 00:08:24,420 These can be parsed in separately as individual rules or together as part of a single rule. 100 00:08:24,930 --> 00:08:28,990 In this example, under the from section we have two elements. 101 00:08:29,400 --> 00:08:31,320 So these are two rules. 102 00:08:31,760 --> 00:08:37,740 The first rule has the pod selector and the namespace selector together and the second rule has the 103 00:08:37,740 --> 00:08:39,090 IP block selector. 104 00:08:39,660 --> 00:08:44,820 So this works like an or Operation Traffic from sources meeting. 105 00:08:44,820 --> 00:08:47,690 Either of these criteria are allowed to pass through. 106 00:08:48,510 --> 00:08:53,250 However, within the first rule we have to select or as part of it. 107 00:08:53,670 --> 00:08:57,180 That would mean traffic from sources I must meet. 108 00:08:57,420 --> 00:08:59,840 Both of these criteria has to pass through. 109 00:09:00,330 --> 00:09:07,590 So they have to be originating from pods with matching labels of APO pod and those parts must be in 110 00:09:07,590 --> 00:09:08,900 the broad namespace. 111 00:09:09,150 --> 00:09:11,730 So it works like and and operation. 112 00:09:12,390 --> 00:09:18,400 Now what if we were to separate them by adding a dash before the namespace selector like this? 113 00:09:19,170 --> 00:09:21,900 Now they are two separate rules. 114 00:09:22,410 --> 00:09:30,990 So this would mean that traffic matching the first rule is allowed, that is from any pod matching the 115 00:09:30,990 --> 00:09:35,850 label API part in any namespace and traffic matching. 116 00:09:35,850 --> 00:09:44,670 The second rule is allowed, which is from any pod within the namespace, and that is either from the 117 00:09:44,670 --> 00:09:50,710 pod web and of course, along with the backup server as we have the IP block specification as well. 118 00:09:51,450 --> 00:09:59,250 So now we have three separate rules and almost traffic from anywhere is allowed to be pod. 119 00:09:59,520 --> 00:10:02,730 So a small change like that can have a big impact. 120 00:10:02,880 --> 00:10:08,340 So it's important to understand how you could put together these rules based on your requirements. 121 00:10:09,290 --> 00:10:15,950 So now let's get rid of all of that and go back to a basic set of rules and will now look at egress, 122 00:10:16,700 --> 00:10:23,810 so say, for example, instead of the backup server initiating a backup, they we have an agent on the 123 00:10:23,810 --> 00:10:26,660 DB part that pushes back up to the backup server. 124 00:10:26,900 --> 00:10:32,630 In that case, the traffic is originating from the database part to an external backup server. 125 00:10:33,260 --> 00:10:36,470 For this, we need to have egress role defined. 126 00:10:37,470 --> 00:10:44,430 So we first add egress to the policy types and then we add a new egress section to define the specifics 127 00:10:44,430 --> 00:10:45,280 of the policy. 128 00:10:46,170 --> 00:10:50,520 So instead of from we now have to under egress. 129 00:10:50,810 --> 00:10:52,320 So that's the only difference. 130 00:10:52,800 --> 00:11:00,490 Under two, we could use any of the selectors, such as a pod namespace or an IP block selector. 131 00:11:00,840 --> 00:11:06,270 And in this case, since the database server is external, we use IP block selector and provide the 132 00:11:06,270 --> 00:11:07,710 site or block for the server. 133 00:11:08,370 --> 00:11:11,820 The port to which the requests are to be sent to is at. 134 00:11:11,850 --> 00:11:14,040 So we specify at the port. 135 00:11:15,320 --> 00:11:22,760 So this rule allows traffic originating from the database part to an external backup server at the specified 136 00:11:22,760 --> 00:11:23,180 address. 137 00:11:24,490 --> 00:11:27,850 Well, that's it for now about network policies and rules. 138 00:11:28,030 --> 00:11:32,550 Head over to the lab and practice working with network policies yourself. 139 00:11:33,130 --> 00:11:34,780 I will see you in the next one.