Kris Nova

Kubernetes is complex, and extremely vulnerable. In 2019 we explored the complexity of the Kubernetes codebase, and the antipatterns therein. This year we want to look at understanding how we observe our cluster at runtime. Let's live code some C and C++ and explore the libraries that bring Wireshark, Falco, and Sysdig to life. We concretely demonstrate how we are able to audit a Kubernetes system, by taking advantage of auditing the kernel's syscall information while enriching this data with meta information from Kubernetes.

We start off by presenting the problem of Kubernetes security at runtime. We discuss concerns with namespace and privilege escalation in a Kubernetes environment. We discover how auditing the kernel gives us visibility into both the container layer, as well as the underlying system layer.

We look at building an eBPF probe, or kernel module to begin auditing syscall metrics. We discover how we are able to pull those out of the kernel into userspace, and start exploring powerful patterns for using these metrics to secure a Kubernetes cluster.

The audience walks away understanding how the kernel treats containers, and how we are able to easily make sense of them. The audience also walks away equipped with an OSS toolkit for understanding, observing, and securing a Kubernetes environment.

Many of us have seen the small PR changing 20 lines with 20 comments and the large PR with over 1k line changes sail through (or stall) with no comments because who has the time to read all that text? What if we could predict areas of the PR that are more likely to need attention?

Many of us have seen the small PR changing 20 lines with 20 comments and the large PR with over 1k line changes sail through (or stall) with no comments because who has the time to read all that text? What if we could predict areas of the PR that are more likely to need attention? This talk will explore creating a model to predict areas of PRs that will generate comments on, using a combination of historic comment data and mailing list stack traces. Then once we’ve built this model we’ll explore how to serve it live with Kubeflow as well as how Kubeflow and K8s can work together to allow us to scale our model training to a larger set of projects.

In this talk we explore the devastating effects using object oriented antipatterns in go while building programs in a monorepo. We look at how we got here in Kubernetes, and how (several years later) we are still working on cleaning up the mess. We explore brilliant refactoring techniques developed because of the original mistakes in Kubernetes.

Unknown to most, Kubernetes was originally written in Java. If you have ever looked at the source code, or vendored a library you probably have already noticed a fair amount of factory patterns and singletons littered throughout the code base. Furthermore Kubernetes is built around various primitives referred to in the code base as “Objects”. In the Go programming language we explicitly did not ever build in a concept of an “Object”. We look at examples of this code, and explore what the code is truly attempting to do. We then take it a step further by offering idiomatic Go examples that we could refactor the pseudo object oriented Go code to.

If the anti patterns weren’t enough we also observe how Kubernetes has over 20 main() functions in a monolithic “build” directory. We learn how Kubernetes successfully made vendoring even more challenging than it already was, and discuss the pitfalls with this design. We look at what it would take to begin undoing the spaghetti code that is the various Kubernetes binaries built from github.com/kubernetes/kubernetes

The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project.