Network Policy with Calico

1 hour
  • 9 Learning Objectives

About this Hands-on Lab

This lab covers the Kubernetes feature of Network Policy. The lab utilizes the `kops` installer to create a cluster using the Calico network overlay. The student is guided through the process of first creating a network policy that prohibits pod access, followed by another policy that grants pod access to certain clients and a named server.

Learning Objectives

Successfully complete this lab by achieving the following learning objectives:

Create the Kubernetes Cluster

The <code></code> script should be in the cloud_user’s home directory. You may list the directory contents with:

$ ls -l

To run the script, enter the following command:

Note: Be sure to have a space between the . and the ./ in front of the script. This ensures that environment variables set in the script are then available to the parent shell.

$ . ./

Once the cluster configuration has been created, you can apply the configuration with this command:

$ kops update cluster -y

Note: To view the cluster servers as they are being created, you may use the aws console and credentials provided.

You may validate the cluster with the command:

$ kops validate cluster

It will give errors until the cluster is fully configured.

When complete, it should report that the cluster is ready.

Verify the cluster is running with:

$ kubectl get nodes
Configure the Required Namespace

To configure a namespace for our lab, you may create a namespace called ‘policy-demo’ by entering:

$ kubectl create ns policy-demo

The command should respond with an affirmation that the namespace was created.

Create the Demo Pods

Run two replicas of the nginx service:

$ kubectl run --namespace=policy-demo nginx --replicas=2 --image=nginx

Expose the service on port 80:

$ kubectl expose --namespace=policy-demo deployment nginx --port=80

Run an interactive session in a pod called access using the busybox image:

$ kubectl run --namespace=policy-demo access --rm -ti --image busybox /bin/sh

Once inside the image, type this command to verify access to the nginx server:

/ # wget -q nginx -O -

This should respond with the raw html from nginx.

To exit the interactive container session:

/ # exit
Enable Isolation

To download the yaml file:

$ wget

To view the yaml file:

$ more default-deny.yaml

To create the policy:

$ kubectl create -f default-deny.yaml
Test Isolation

To view that the nginx pods are running:

$ kubectl --namespace=policy-demo get pods

To run an interactive container to test access:

$ kubectl run --namespace=policy-demo access --rm -ti --image busybox /bin/sh

Within the access container, enter:

/ # wget -q --timeout=5 nginx -O -

Note: You should receive a timeout in 5 seconds.

To exit the container shell:

/ # exit
Allow Restricted Access Using a Network Policy

To download the yaml file:

$ wget

To look at the file:

$ more access-nginx.yaml

To create the policy:

$ kubectl create -f access-nginx.yaml
Verify Access to nginx from the access Pod

Run an interactive pod called access with an interactive shell:

$ kubectl run --namespace=policy-demo access --rm -ti --image busybox /bin/sh

Once inside the container session, test nginx access:

/ # wget -q --timeout=5 nginx -O -

Note: Since we are in a pod named ‘access’ we should be able to access the nginx service.

To exit the container shell:

/ # exit
Verify That Access to nginx Is Not Allowed from Another Pod

Run a container shell in a pod called ‘not-access’:

$ kubectl run --namespace=policy-demo not-access --rm -ti --image busybox /bin/sh

Within the container attempt to access nginx:

/ # wget -q --timeout=5 nginx -O -

Note: This command should timeout after 5 seconds.

To exit the container shell:

/ # exit
Delete the Namespace to Clean Up

To delete the namespace and thus terminate the running pods and nullify the network policies created, enter:

$ kubectl delete ns policy-demo

Additional Resources

The lab's bastion server will be created and the student will need to use ssh to gain access to the server. An AWS console instance has also been provided so that the student may view the EC2 instances created by the kops installer.

Basic Kubernetes knowledge is required to perform this lab.

What are Hands-on Labs

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?