VSHN.timer #8: Kubernetes Security

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system and making us think, laugh, or simply work better.
This week we are going to talk about Kubernetes security; hang tight, this is a hot topic and there is a lot of material in this edition!

1. We cannot start a security–related issue of VSHN.timer without mentioning the breaking news of a major security audit of Kubernetes, which raised 34 major vulnerabilities in about two million lines of code. The Cloud Native Computing Foundation mandated Trail of Bits and Atredis Partners to perform this audit, spanning from encryption to networking to storage to every other aspect of Kubernetes. This report triggered the immediate release of new versions of Kubernetes: 1.13.9, 1.14.5, and 1.15.2 – and then later 1.13.10, 1.14.6 and 1.15.3 to fix vulnerabilities in the net/http library of the Go language as well. It goes without saying that this step marks a major milestone in the history of Kubernetes and cloud-native apps.

https://www.theregister.co.uk/2019/08/06/kubernetes_security_audit/
2. All systems are as secure as their weakest part. This means that developers deploying applications in Kubernetes have to take care of a myriad of factors. For example, end-to-end encryption. Red Hat published a tutorial recently about how to configure secure end-to-end communications in cloud native apps. Since you are hardening your cluster, you might want to give developers the least possible level of privilege, learn how to properly get a shell to a kubernetes node, and learn more about etcd.
https://blog.openshift.com/self-serviced-end-to-end-encryption-for-kubernetes-applications-part-2-a-practical-example/
3. The risks of misuse and misconfiguration of Kubernetes are indeed huge. Take what Mate Ory from Banzai Cloud explains in this blog post for example. A badly configured (or downright malicious) kubeconfig file can leak confidential information such as keys and credentials, and even execute shell commands in a compromised cluster – while at the same time cleaning up its own traces! As a bonus, the Banzai team has released the kubeconfigurer tool to verify kubeconfig files for precisely those security issues. An absolute must read.
https://banzaicloud.com/blog/kubeconfig-security/
4. And just like with any other new and hyped technology, things can go wrong with Kubernetes. Very fast and very wrong. And not only from a security point of view. To stay updated (and to learn a few things that might help harden your cluster in the future) the Kubernetes Failure Stories website provides a compilation of public failure & horror stories related to our favorite cloud native technology. Worth a few facepalms. At least. And in case you did not get enough, well, this postmortem of Debian’s failed Docker registry move might make your day.
https://k8s.af/
5. To finish this unfortunately gloomy edition of VSHN.timer, here’s a link to the OWASP Container Security Verification Standard, a „community-effort to establish a framework of security requirements and controls that focus on normalizing the functional and non-functional security controls required when designing, developing and testing container-based solutions with a focus on Docker.“ In this brave new world of ours, we need more of these initiatives.
https://github.com/OWASP/Container-Security-Verification-Standard
Would you like to share other Kubernetes security-related links with us? Have you had suffered serious security incidents while deploying Kubernetes? Do you have any best practices you would like to share with the community? Get in touch with us using the form below, and see you next week for another edition of VSHN.timer.