We have all heard that Kubernetes is Secure and Kubernetes Isolates your Apps, but you will be surprised to learn that actually it is not very secure if you deploy your apps wrong. There are many ways in which apps deployed with Kubernetes can be deployed in insecure ways, and this will ultimately result in your apps not being isolated.
Why does this matter? If an app is not isolated in Kubernetes, then if one app in Kubernetes was hacked, the hacker could then spread to the underlying Kubernetes infrastructure, spidering out and exploiting other apps or other servers.
Kubesec helps with this by auditing your Kubernetes pod specification (the definition of what you are deploying) and providing guidance on ways you could improve how you are deploying your pods such that their privileges are limited to ensure proper isolation between the apps you are deploying on Kubernetes.
How to Use KubeSec
You provide a pod spec to KubeSec and then it provides back a list of potential issues you should consider addressing. It is included in M9sweeper, but it can also be called stand-alone as a CLI tool.
First, you need to get your pod’s specification in yaml:
kubectl get pod [mypodname] -n [mynamespace] -o yaml > podspec.yaml
Then, you need to pass this to kubesec:
kubesec scan podspec.yaml
More about installing and using kubesec is available at https://kubesec.io/
What Kinds of Things Should I Be Worried About?
Here are a few common things that Kubesec will identify as potential improvements:
- Limiting Kernal Privileges: Using SE Linux Profiles or AppArmor profiles, you can limit application’s privileges preventing things like privilege escalation or modifying network routing tables.
- Not Allowing Privilege Escalation: Preventing applications from attempting to escalate their privileges.
- Not Allowing Writing to File System: Writing to the file system can cause the harddrive to run out of disk storage, potentially allowing one app to interfere with others.
- Preventing Running as Root and/or specifying user to run as: By explicitly running as a non-root user as well as blocking running as root, insecure images will not inadvertently run as the root user (who has all linux kernel privileges).
- Limiting applications CPU or Memory: If an app has no limits, it can perform poorly in a DOS attack, interfering with the performance of other apps on the server.
- Mounting Host Storage: If an app can mount a host volume, it can potentially mount the root folder of the host file system (or other pod’s folders), which could be used by a bad actor to escalate privileges or gain access to sensitive data.
How do I make sure others are following best practices?
We recommend using Gatekeeper policies to enforce the kubesec best practices. Our built-in library of Gatekeeper constraint templates is based upon the pod security policies and can be used to enforce that every pod deployed in your cluster follows best practices with regards to limiting privileges.
Also, our application can run kubesec on any pod in your cluster by clicking the kubesec button on the top right when viewing the pod.
