Cluster Setup

Network Security Policies

Network Policies

Network policies are:

• Firewall rules in k8s.

• Implemented by the Network Plugins CNI (Calico, Weave)

• Namespace Level

• Restrict the Ingress and/or Egress for a group of pods based on certain rules and conditions.

Without Network Policies:

• Every pod can access every pod.

• Pods are not isolated.

We can apply network policies using:

• Pod Selector

• Namespace Selector

• ipBlock

Multiple Network Policies

We can have multiple NPs selecting the same pods.

If a pod has more than one NP:

• Then the union of all NPs is applied.

• Order doesn't affect policy results.

Practical

Default Deny All

Allow Frontend Pods to talk to backend Pods

We need to set an egress rule for frontend pod so it can send traffic to the backend pod.

After that, we need to allow ingress rule on the backend pod so it can receive traffic from the frontend pod

**Due to the default-deny policy we created, it also blocks dns resolution, which means we can't run **kubectl exec frontend -- curl backend instead we have 2 choices:

1. Get the IP of the backend and frontend and use them in the command using kubectl get po -o wide.

2. We can create an egress policy to allow dns on port 53:

Allow backend pods to talk to database pods

• Add egress rule to backend pod network policy with a namespaceSelector.

• Create a new ingress rule for cassandra pod in cassandra namespace with a podSelector rule to allow backend pod traffic.

GUI Elements

Installing kubernetes dashboard

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard

Secure Ingress

How does ingress work?

Setting up an example ingress

1. Deploy the ingress-controller:

 k apply -f https://raw.githubusercontent.com/killer-sh/cks-course-environment/master/course-content/cluster-setup/secure-ingress/nginx-ingress-controller.yaml

1. Create an ingress resource which points to 2 services and the 2 services points to the pods respectively.

2. Run 2 pods and expose them on port 80

3. Test by running curl on the cks-master public ip and the NodePort of the ingress-controller:

curl http://x.x.x.x:34313/service1
curl http://x.x.x.x:34313/service2

Securing our example ingress

Now, we will do the same as before, but instead of

When trying to curl with https, we get an error:

A workaround would be to specify the -k (accept self-signed certificates) and it will work.

Also we can specify the -v flag to check debug outputs, we can see from it the fake certificate we are using which leads to the original error.

Protect Node Metadata and Endpoints

Cloud Platform Node Metadata

Cloud providers manage metadata server and the instances we spin up have access to these metadata servers.

Restrict access using Network Policies

Containers running on cloud instances have access to the metadata service, so what we can do is create network policies to allow/deny certain containers from accessing the metadata service.

CIS Benchmark

• Best practices for the secure configuration of a target system

• Covering more than 14 technology groups

CIS Benchmark has a PDF where you can see the defaults ok k8s security measures and the corresponding best practices for it, so you must apply the best practices.

Note: In exam you would have some rules and you must apply them, you don't need to access the PDF.

Running Kube-bench

https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md

We will be fixing 1.1.12

We go to the CIS Benchmark PDF to check the solution for it.

Now, we can run the Kube-bench command again to confirm it worked:

Every cloud provider has its own CIS Benchmarks for its managed kubernetes cluster, take a look at GKE CIS Benchmarks:

https://cloud.google.com/kubernetes-engine/docs/concepts/cis-benchmarks

Verify Platform Binaries

Hashes

Every file has a unique fingerprint that can be generated using a hash, there are different algorithms to generate hashes (MD5, SHA1 etc...)

We can run sha512 sum command to check the hash of any file, then we can add it to a file and paste under it the original hash and then we can run cat compare.txt | uniq, if we got a single line as output, then both hashes are the same.

For example to compare the hash value of kube-api server binary:

• Download the latest kube-api server and run sha256 sum on it.

• Get our own kube-api server binary by running ps aux | grep apiserver and getting the process number (e.g: 1444).

• After that we can run find /proc/1444/root/ | grep kube-api to get the full path of our current kube-api server binary.

• Then run on the path sha256sum.

• Compare both sums by piping them into uniq