Working with Kubernetes NetworkPolicies

Hands-On Lab

 

Photo of Will Boyd

Will Boyd

DevOps Team Lead in Content

Length

01:00:00

Difficulty

Intermediate

By default, Kubernetes pods have unrestricted network access both inside and outside the cluster. However, it is often desirable to restrict network access to and from pods, particularly for security reasons. Kubernetes NetworkPolicies provide a flexible way to implement these networking restrictions, giving you control over all of the network traffic involving your pods. In this lab, walk through NetworkPolicies concepts, and examine some existing policies to determine how we can properly apply them to a pod.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Working with Kubernetes NetworkPolicies

The scenario

Our company has a set of services, inventory-svc and customer-data-svc. In the interest of security, both of these services and their corresponding pods have NetworkPolicies designed to restrict network communication to and from them. A new pod has just been deployed to the cluster called web-gateway, and this pod needs to be able to access both inventory-svc and customer-data-svc.

Unfortunately, whoever designed the services and their corresponding NetworkPolicies was a little lax in creating documentation. In top of that, they are not currently available to help anyone understand how to provide access to the services for the new pod.

Get logged in

Use the credentials and server IP in the hands-on lab overview page to log in with SSH.

Provide the web-gateway Pod with Network Access to the Pods Associated with the inventory-svc Service

First, let's get a list of existing NetworkPolicies:

[user@host]$ kubectl get networkpolicy

Examine inventory-policy more closely:

[user@host]$ kubectl describe networkpolicy inventory-policy

Note that the policy selects pods with the label app: inventory, and provides incoming and outgoing network access to all pods with the label inventory-access: true.

We can test access to the inventory-svc with this:

kubectl exec web-gateway -- curl -m 3 inventory-svc

This will time out though. Let's get into web-gateway and see if we can fix things.

Modify the web-gateway pod with kubectl edit pod web-gateway. This is going to dump us into a Vim instance. Press i to get into insert mode, make changes, then Esc, and then wq! ro save and quit. Here are the changes we need to make:

Add the inventory-access: "true" label to the pod under metdadata.labels.

...
metdadata:
  labels:
    inventory-access: "true"
...

Now lets see if the curl command works:

kubectl exec web-gateway -- curl -m 3 inventory-svc

We should see an nginx welcome page.

Provide the web-gateway Pod with Network Access to the Pods Associated with the customer-data-svc Service

Examine customer-data-policy more closely:

kubectl describe networkpolicy customer-data-policy

Note that the policy selects pods with the label app: customer-data, and provides incoming and outgoing network access to all pods with the label customer-data-access: true.

Modify the web-gateway pod with kubectl edit pod web-gateway. This is going to dump us into a Vim instance again.

Add the customer-data-access: "true" label to the pod under metdadata.labels:

...
metdadata:
  labels:
    inventory-access: "true"
    customer-data-access: "true"
...

Test access to the customer-data-svc like so:

kubectl exec web-gateway -- curl -m 3 customer-data-svc

We'll get an nginx welcome page again. That's great.

Conclusion

By simply examining the existing NetworkPolicies, we were able to get all of the moving parts talking by simple altering the web-gateway pod. We didn't need to add, delete, or edit any NetworkPolicies in order to do this. Congratulations!