In this lecture, we will take a look at network policies in more detail.
So here we have the same Web API and database parts that we discussed about in the previous lecture.
So first, let's be very clear with our requirements.
Our goal is to protect the database part so that it does not allow access from any other part except
the API part and only on PT. three three zero six.
So let's assume that we are not concerned about the Web or the API part for those parts.
We are OK for all traffic to go in and out from anywhere.
However, we want to protect the database part and only allow traffic from the API part.
So let's get the other things out of our way so we can focus exactly on the required tasks.
So we don't need to worry about the Web pod on its support as we don't want to allow any traffic from
any other sources other than the API part.
So let's get rid of that.
We can also forget about the port on the API part to which the Web server connects as we don't care
about that either.
As we discussed by default, cabernets allows all traffic from all parts to all destinations, so as
the first step, we want to block out everything going in and out of the database part.
So we create a network policy.
We will call it DB policy.
And the first step is to associate this network policy with the part that we want to protect.
And we do that using labels and selectors.
So we do that by adding a part selector field with the match labels option and by specifying the label
on the DB part, which happens to be set to roll to be.
And that associates the network policy with the database pod and blocked out all traffic, however,
we need the API part to be able to carry the database on four three three zero six.
So that's what we are going to configure next.
First, we need to figure out what type of policies should be defined on this network policy object
to meet our requirements.
So there are two types of policies that we discussed in the previous lecture.
We have ingress and egress.
So do we need ingress or egress here or both?
So you always look at this from the deep parts perspective, from the DB parts perspective, we want
to allow incoming traffic from the API part.
So that is incoming.
So that is ingress.
The API part makes database queries and the database pods returns the results.
So what about the results?
Do you need a separate rule for the results to go back to the airport?
No, because once you allow incoming traffic, the response or reply to that traffic is allowed back
automatically.
We don't need a separate rule for that.
So in this case, all we need is an increased rule to allow traffic from the airport to the database
part, and that would allow the airport to connect to the database and run queries and also retrieve
the result of the queries.
So when deciding on what type of rule is to be created, you only need to be concerned about the direction
in which the request originates and which is denoted by the straight line here.
And you don't need to worry about the response, which is denoted by the dotted line.
However, this rule does not mean that the database part will be able to connect to the airport or make
calls to the API.
See, for example, the database pod tries to make an API call to the API pod, then that would not
be allowed because that is now an egress traffic originating from the database pod and would require
a specific egress rule to be defined.
So I hope you get the difference between the two and are clear about ingress and egress rules.
I just wanted to make sure that you're clear on what type of policy is to be selected for the requirement
that you have in hand.
So a single network policy can have an ingress type of role and egress type of rule or both in cases
where a party wants to allow incoming connections as well as wants to make external calls.
So for now, our use case only requires increased policy types.
Now that we have decided on the type of policy, the next step is to define the specifics of that policy.
If it's ingress, we create a section called Ingress within which we can specify multiple rules.
Each rule has a from and ports feels the from field defines the source of traffic that is allowed to
pass through to the database part.
And here we would use a part selector and provide the labels of the API pod like this.
The sports field defines what sport on the database part is, the traffic allowed to go to.
In this case, it's three three zero six with the TCP protocol and that's it.
This would create a policy that would block all traffic to the DB part except for traffic from the API
part.
Now, what if there are multiple airports in the cluster with the same labels, but in different name
spaces, so say here we have different name spaces for dev test and prod environments, and we have
the airport with the same labels in each of these environments.
The current policy would allow any part in any namespace with matching labels to reach the database
part.
We only want to allow the API part in the namespace to reach the database part.
So how do we do that?
For this we add a new selector called as the namespace selector property and along with the selector
property.
Under this we use match labels again to provide a label set on the namespace.
And you must remember that you must have this label set on the namespace first for this to work.
So that's what the namespace selector does, it helps in defining from what namespace traffic is allowed
to reach the database part.
Now, what if you only have the name space selector and not the pod selector like this, in this case,
all pods within the specified namespace will be allowed to reach the database pod, such as the Web
part that we had earlier.
But parts from outside this namespace won't be allowed to go through.
Let's look at another use case, say we have a backup server somewhere outside of the cornetist cluster
and we want to allow the server to connect to the database pod.
Now, since this backup server is not deployed in our current cluster, the pod selector and namespace
electric fields that we use to define traffic from won't work because it's not a part in the cluster.
However, we know the IP address of the backup server, and that happens to be 190 to that 168 or five
or 10.
We could configure a network policy to allow traffic originating from certain IP addresses.
For this, we add a new type of from definition known as the IP block definition IP block allows you
to specify a range of IP addresses from which you could allow traffic to hit the database pod.
So those are three separate selectors under the front section and ingress.
And these are also applicable to the two section in egress.
And we'll see that in a few minutes.
We have pod selector to select pod by labels.
We have namespace selector to select namespace by labels and we have the IP block selector to select
IP address ranges.
These can be parsed in separately as individual rules or together as part of a single rule.
In this example, under the from section we have two elements.
So these are two rules.
The first rule has the pod selector and the namespace selector together and the second rule has the
IP block selector.
So this works like an or Operation Traffic from sources meeting.
Either of these criteria are allowed to pass through.
However, within the first rule we have to select or as part of it.
That would mean traffic from sources I must meet.
Both of these criteria has to pass through.
So they have to be originating from pods with matching labels of APO pod and those parts must be in
the broad namespace.
So it works like and and operation.
Now what if we were to separate them by adding a dash before the namespace selector like this?
Now they are two separate rules.
So this would mean that traffic matching the first rule is allowed, that is from any pod matching the
label API part in any namespace and traffic matching.
The second rule is allowed, which is from any pod within the namespace, and that is either from the
pod web and of course, along with the backup server as we have the IP block specification as well.
So now we have three separate rules and almost traffic from anywhere is allowed to be pod.
So a small change like that can have a big impact.
So it's important to understand how you could put together these rules based on your requirements.
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,
so say, for example, instead of the backup server initiating a backup, they we have an agent on the
DB part that pushes back up to the backup server.
In that case, the traffic is originating from the database part to an external backup server.
For this, we need to have egress role defined.
So we first add egress to the policy types and then we add a new egress section to define the specifics
of the policy.
So instead of from we now have to under egress.
So that's the only difference.
Under two, we could use any of the selectors, such as a pod namespace or an IP block selector.
And in this case, since the database server is external, we use IP block selector and provide the
site or block for the server.
The port to which the requests are to be sent to is at.
So we specify at the port.
So this rule allows traffic originating from the database part to an external backup server at the specified
address.
Well, that's it for now about network policies and rules.
Head over to the lab and practice working with network policies yourself.
I will see you in the next one.