This is the solution video for the Network Policies Lab. So for the first question, we have to identify
the number of network policies in the environment.
To do this, let's go to the terminal and type cubicle, get netball, which is short for network policy.
And here we can see that there is a single network policy in the default namespace by the name of payroll
Dasch policy.
So the answer is one.
What is the name of the new policy?
It is payroll tax policy.
Which part is the network policy applied on to here we can see the port selecter, which is name is
equal to payroll, so let's use it will get pots and check the label of the port, which is using the
specific label.
So for will use the shell option
and along with that will provide the label name as equal to payroll and hear the name of the port,
but with the specific label as payroll itself.
So let's select that as our answer.
What type of traffic is this network policy configured to handle to find us, let us run still describe
network policy.
And in here, we should be able to see the policy type, which is used for policy type as ingress.
And again, here you can see the pod selector here as well, which is using the label name is called
Aperol.
But the type of policy that this configuration uses as the ingress type, as you can see, it's not
affecting egress traffic.
So the answer is in increase.
What is the impact of the rule configured on this policy?
So let's go back and we already know that this is an insurance policy and it is allowing increased traffic
to port at the port from the port or the port selecter, which has the label name as equal to internal.
So it's allowing traffic from a board with this label name is equal to Internal to Port 880 on the port,
which has the label payroll, which is the port by the name of payroll.
So let's identify the port, which has the label name, as you called the internal.
And here you can see that the name of the pot is internal as well.
So traffic.
From Internal to Peyrol Borders blog, that strong traffic from internal to payroll borders.
So that's a great option.
What is the impact of the rule configured on those network policy, so we already figured that out internal
pod can access Port 88 on the payroll pod, so that's a great option.
Access the UI of these applications using the link above the terminal.
So let's go and check that out.
So there are two tabs here.
One is for the external portal and the other one is for internal portal.
So let's open those up, make sure that it's working.
And here we can run connectivity to so yeah, we are able to open these two portals.
Perform a connectivity test using the user interface and these applications to access DiPiero service
are at 8:00.
So let's use.
The service name and test on both the poodle's.
And you can see that we are getting a successful connectivity test from the Internet facing application,
let's do the same for the external facing application.
And this one is coming out, so let's check for the correct option, only internal application can access
the burial service.
That is correct.
Perform a connectivity test using the user interface of the internal application to access the external
service I bought.
So, again, this has to be run in the internal portal.
So let me copy this.
And here, we'll test for external service.
And that is successful as well.
So it is successful, so from the internal part, we know that we are able to connect to put 88 on the
parole board, but it is also allowing connectivity to the external port on board 880 so that successful.
And the next question, we have to create a network policy to allow traffic from the internal application
only to the payroll service and delivery service from the internal application, we have already opened
the connectivity to.
Payroll board and should also allow connectivity to DV service, which is about three three zero six
part to extoll part, it should be blocked.
So this has to be an egress type policy.
The name of the policy should be internal policy egressed allow should be to parole and to DV and it
should block egress to the external pod.
So the connectivity, this connectivity to excellent service on board, it should not be allowed.
So that's what we are trying to block by creating an egress type network policy.
So for this, we'll make use of it as documentation.
There is no straightforward way to create a network policy using imperative comments, so we'll have
to rely on the documentation and use the examples provided there.
So we just type in network policy and it should come up with the result, the first one as the most
appropriate one, it has examples of network policy template here.
So we can copy this exact same example.
And we will modify it to suit our needs, so we just need to create this policy for egress, so remove
everything related to injuries.
I'm just going to copy it.
And the name of the policy letters name the file with the same one as well.
So it's called internal US policy.
I'm just going to sit here.
And let's start making changes, so let's see if this policy has a name, the policy name is also yeah,
obviously it is internal policy.
So let's change that.
And we know that this is an egressed type of policy on the internal part, so will change the match
labels to name as a call to internal.
We have already checked the label for this earlier.
And this is an Eagles only policy, so I'm going to remove ingress and let's remove the ingress section
here.
And let's keep the egress one.
So we don't need the IP block.
All right, so now we have a template and we can use this to update our configuration.
OK, so underneath this we will define the pods, the pod selector.
So, again, let's go back to the example.
So I'm just going to copy the pod selector here.
So the first one will use us for the MySQL, but let's just copy the template again.
Support for my sequel should be three three zero six.
And let's take the service name and the label for the mythical part.
So my sequel part has a label of name, a sequel to my sequel, so let's update that.
And similarly, let us also add the egressed to payroll, so I'm just going to copy paste, the easiest
way is to cad the same file.
And right, click select, right, click, copy and paste.
So that's one easy way of doing it.
So I'm just going to repeat the same thing.
So this.
I'll have to add another tuffield here.
Make sure that it is correctly indented so the need for this should be.
We already know that it should be Peyro.
The port should be DCP Port at 80.
So egoless, allow Peyrol put it 80 egoless Lomis equal or two three three zero six, so that looks
correct.
So we are allowing egress from the internal port.
Only to the parole and the report, and it's cutting out the connectivity to everything else, so this
connection here should not work anymore once we apply the policy.
Another thing to note is that sometimes Adina's resolution might fail from the internal part because
it's not able to raise the cube DNS servers on DCP and jury people 53.
So if that happens, that's something that you'll have to add in as well.
But just for the sake of this test, where we are adding to egressed rules to effectively allow communication
only to the MySQL and the parole board, there should be enough.
So let's see if this has been created correctly.
So we'll try to create this network policy now.
Let's see if that worked, so, yeah, it looks like it did work.
Let's turn to Cuba, still describe.
And here you can see that the egress policy type is in effect, there are two egress traffic's one as
to the mythical port and the port is three three zero six.
The other one is espero to 880.
So these two are to allow rules.
So let's check and see if that was created correctly.
And was so that was the last question.
Thank you for joining me in this solution video.
I'll see you in the next one.