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:
Get the IP of the backend and frontend and use them in the command using
kubectl get po -o wide.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
Secure Ingress
How does ingress work?
Setting up an example ingress
Deploy the ingress-controller:
Create an ingress resource which points to 2 services and the 2 services points to the pods respectively.
Run 2 pods and expose them on port 80
Test by running curl on the cks-master public ip and the NodePort of the ingress-controller:
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
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:
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:
Get our own kube-api server binary by running
ps aux | grep apiserverand getting the process number (e.g: 1444).After that we can run find
/proc/1444/root/ | grep kube-apito 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
Last updated
