Site icon CormacHogan.com

A first look at Network Policies in Tanzu Mission Control

Some time back, I wrote a blog post about how to use the network policies available with the Antrea CNI (Container Network Interface). In that post we looked at how to create a simple network policy to prevent communication between pods in a Tanzu Kubernetes cluster, based on pod selectors / labels. We stood up a simply web server and a standalone pod, and showed how the pod could access the web server when no network policies were in place. We then proceeded to create a network policy that only allowed pods to communicate to each other if the pod selector / label matched the rule defined in the policy. In this post, I am going to look at how to do the same operation in Tanzu Mission Control. Again, the Kubernetes cluster will be TKG v1.3.1 (K8s 1.20.5). I will create a namespace, then create a Nginx deployment + service along with a standalone busybox pod. To begin, the busybox will have a different label to Nginx. We will show how, without a network policy, the busybox pod can communicate with the Nginx service. We will then implement a network policy that only allows pods with a certain label to communicate, so in this case, the busybox pod will no longer be able to communicate with the web server. Finally, we will change the pod selector / label rule in the network policy to match that of the busybox pod and we should see successful communication once again.

Step 1 – Create namespace and apps

I created a namespace called network-testing on my TKG cluster. I deployed the Nginx application, and my standalone busybox pod. Note how they have different labels as shown by the APP column. Also note the Cluster-IP address for the Nginx service, highlighted in blue below. We will be using this to test communication between the pods.

$ kubectl get all -n network-testing -L app
NAME                              READY  STATUS    RESTARTS  AGE    APP
busybox                           1/1    Running  0          9m1s  busybox
nginx-deployment-585449566-8p27j  1/1    Running  0          9m9s  nginx
nginx-deployment-585449566-nsd7k  1/1    Running  0          9m9s  nginx
nginx-deployment-585449566-rqfp5  1/1    Running  0          9m9s  nginx

NAME                TYPE          CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE  APP
service/nginx-svc  LoadBalancer  100.67.183.176  10.35.14.224  443:31991/TCP,80:30903/TCP  21m  nginx

NAME                              READY  UP-TO-DATE  AVAILABLE  AGE  APP
deployment.apps/nginx-deployment  3/3    3            3          21m

NAME                                        DESIRED  CURRENT  READY  AGE  APP
replicaset.apps/nginx-deployment-585449566  3        3        3      21m  nginx

Step 2 – Verify pod communication without network policy

To make sure we have pod to pod communication in place without any network policy created, we can use the following test. After opening a shell to the busybox pod, we should be able to run a wget against the Cluster-IP of the Nginx service and retrieve the web server landing page, as shown below. This demonstrates that there is communication between the different pods.

$ kubectl exec -it busybox -n network-testing -- sh
/ # wget -q -O - 100.67.183.176
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ #

We can now try to control this communication with a network policy.

Step 3 – Create a Workspace in Tanzu Mission Control

In order to be able to create a network policy in Tanzu Mission Control (TMC), it must be created at the workspace level. A workspace is an organizational tool that helps you monitor and manage your Kubernetes namespaces within and across clusters. Creating the workspace is very simple. From the main TMC landing page, there is a Workspace link on the left-hand navigation bar. Click on this, and then click on the button to Create Workspace. Give it a name, and optional description and optional labels, and that is it. For this example, I created a workspace called network-testing-ws.

Step 4 – Attach the namespace to the Workspace in TMC

Once the workspace is created, add your namespace to it. As previously mentioned, I created a namespace called network-testing for this post. To add this namespace to the workspace, select Namespaces from the navigation bar on the left-hand side, select the namespace that you want to attach, and then click the Attach button. With the namespace now attached to the workspace, we can proceed with the creation of the network policy. In this screenshot, I have attached my network-testing namespace to the network-testing-ws workspace.

Step 5 – Navigate to ‘create a network policy’

Network policies can only be created at the workspace level. They cannot be created at cluster level or at a namespace level. Thus, to get to the point where you can create a network policy, you must first expand the Policies section in the left-hand navigation bar. This will show a sub-menu item called Assignments. Click on this and it will take you to the Policies section. Across the top, there will be a number of menu items. Select Network. Now you have the option of selecting Cluster or Workspace. If Cluster is selected, it will tell you that you cannot set network policies at the cluster level, only at the workspace level. Select Workspace, and then select the workspace you want to create a policy on. In our case, the workspace is network-testing-ws. Now you should see the option to create a network policy on the right hand side of the window.

Step 6 – Create a Network Policy

Click on the Create Network Policy link shown above. For the purposes of this demonstration, I am going to create a custom-ingress policy. I will give the policy a name, called nginx-allow. The pod selector, to identify which pods this rule applies, will be the pod selector / label app:nginx. Click on the Add Label button to save it.

Now we need to add the rule regarding who can have ingress access to Nginx. I changed the From: field to be Selector rather than IP Block, and stated that only pods with the app:nginx label (Pod Selector) can have  ingress access. This should mean that our busybox pod no longer have access to the web-server.

Save the policy by click on the Create Policy button at the bottom. The new rule should now be associated with the namespace.

Step 7 – Test that the network policy is working

To test that the policy is working, try to access the web server from the busybox pod as before.

$ kubectl exec -it busybox -n network-testing -- sh
/ # wget -q -O - 100.67.183.176
wget: can't connect to remote host (100.67.183.176): Connection timed out

It would seem that the policy has successfully taken effect, and we are no longer able to access the web server because our busybox pod does not have the correct pod identifier / label.

Step 8 – Verifying with a different Pod Selector

There are two ways that you could allow the busybox pod to communicate to the web server. The first is to change the label on the busybox pod so that it has a label of app:nginx, or the alternate method is to change the rule in the policy, and modiy the pod selector from app:nginx to app:busybox. If we do the latter, the rule would look similar to the following:

After saving the rule, our wget command from the busybox pod to the web server service should start working again.

/ # wget -q -O - 100.67.183.176 | grep title
<title>Welcome to nginx!</title>

Success! Finally, we can examine the network policy object that was created in our TKG cluster namespace by using the following kubectl commands.

$ kubectl get networkpolicy -A
NAMESPACE        NAME                                  POD-SELECTOR  AGE
network-testing  tmc.wsp.network-testing.nginx-allow  <none>        12m


$ kubectl describe networkpolicy -n network-testing
Name:        tmc.wsp.network-testing.nginx-allow
Namespace:    network-testing
Created on:  2021-11-04 11:57:38 +0000 GMT
Labels:      tmc.cloud.vmware.com/managed=true
Annotations:  <none>
Spec:
  PodSelector:    app=nginx
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: app=busybox
  Not affecting egress traffic
  Policy Types: Ingress

You can find our more information around rules that can be used in network policies in the official documentation.

Exit mobile version