Hello and welcome to this lecture on network policies.
So let us first get our networking and security basics right.
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
on the same page.
Before we begin we will start with a simple example of a traffic flowing through a web app and database
server so you have a web server serving front-end to users an app server serving back-end API and
a database server.
The user sent in a request to the web server at port 80 the web server then sent a request to the API
server at port 5000 in the back end.
The API server then fetches data from the database server at Port 3306 and then sends the data back
to the user.
A very simple setup so there are two types of traffic here ingress and egress.
For example for a web server the incoming traffic from the users is an ingress traffic and the outgoing
request to the app server is a egress traffic and that is denoted by the straight arrow.
When you define ingress and egress remember you're only looking at the direction in which the traffic
originated.
The response back to the user denoted by the dotted lines do not really matter.
Similarly in case of the back end API server it receives ingress traffic from the web server on port
5000 and has egress traffic to port 3306 to the database server and from the database
servers perspective it receives ingress traffic on 3306 from the API server.
If we were to list the rules required to get this working we would have an ingress rule that is required
to accept HTTP traffic on port 80 on the web server. An Egress rule to allow traffic from the web server
to port 5000 on the API server. An ingress rule to accept traffic on port 5000 on the API server and
an egress rule to allow traffic to port 3306 on the database server.
. And finally an ingress rule on the database server to accept traffic on port 3306.
So that's the basic of traffic flow and rules.
Let us now look at Network Security in Kubernetes.
So we have a cluster with a set of nodes hosting a set of pods and services.
Each node has an IP address and so does each pod as well as service. One of the pre-requisite for networking
in kubernetes, is whatever solution you implement, the pods should be able to communicate with
each other without having to configure any additional settings like routes.
For example, in this network solution, all pods are on a virtual private network that spans across
the nodes in the kubernetes cluster. And they can all by default reach each other using the IPs
or pod names or services configured for that purpose.
Kubernetes is configured by default with an “All Allow” rule that allows traffic from any pod to any other
pod or services. Let us now bring back our earlier discussion and see how it fits
in to kubernetes. For each component in the application we deploy a POD. One for the front-end web server,
for the API server and one for the database.
We create services to enable communication between the PODs as well as to the end user. Based on what
we discussed in the previous slide, by default all the three PODs can communicate with each other within
the kubernetes cluster. What if we do not want the front-end web server to be able to communicate with
the database server directly say for example your security teams and audits require you to prevent that
from happening.
That is where you would implement a Network Policy to allow traffic to the db server only from the api
server. A Network policy is another object in the kubernetes namespace.
Just like PODs, ReplicaSets or Services.
You link a network policy to one or more pods.
You can define rules within the network policy.
In this case I would say, only allow Ingress Traffic from the API Pod on Port 3306.
Once this policy is created, it blocks all other traffic to the Pod and only allows traffic that matches
the specified rule.
Again, this is only applicable to the Pod on which the network policy is applied.
So how do you apply or link a network policy to a pod.
We use the same technique that was used before to link ReplicaSets or Services to Pods. Labels and Selectors.
We label the Pod and use the same labels on the pod selector field in the network policy. And then
we build our rule under policy types specify whether the rule is to allow ingress or egress traffic
or both.
In our case we only want to allow ingress traffic to the db-pod. So we add Ingress.
Next, we specify the ingress rule, that allows traffic from the API pod. And you specify the api pod, again
using labels and selectors.
And finally the port to allow traffic on, which is 3306.
Let us put all that together.
We start with a blank object definition file and as usual we have apiVersion, kind,
metadata and spec. The apiVersion is networking.k8s.io/v1,
the kind is NetworkPolicy. We will name the policy db-policy. And then under the spec section,
we will first move the pod selector to apply this policy to the db pod. Then we will move the rule
we created in the previous slide under it and that's it.
We have our first network policy ready. Run the kubectl create command to create the policy. Remember
that Network Policies are enforced by the Network Solution implemented on the Kubernetes Cluster. And not
all network solutions support network policies.
A few of them that are supported are kube-router, Calico, Romana and Weave-net.
If you used Flannel as the networking solution, it does not support network policies
as of this recording. Always refer to the network solution’s documentation to see support for network
policies.
Also remember even in a cluster configured with a solution that does not support network policies you
can still create the policies but they will just not be enforced.
You will not get an error message saying the network solution does not support network policies.
Well, that’s it for this lecture. Walk through the documentation and head over to coding challenges
to practice network policies.