'Unsafe Defaults: Deploying Kubernetes Safer(ish)' - James (LCA 2020)

James

Sometimes evil conglomerates, large companies and/or totally regular and normal individuals prefer to run Kubernetes themselves, instead of using a public cloud provider - perhaps they don't trust the InterGoogles, perhaps they want to experience the incessant joys of maintenance and upgrades themselves, or perhaps (THE REAL REASON) they wanted to justify their sweet, sweet devops stickers on their laptop.

Sure, not trusting someone else's computer make sense in some threat models, the (sometimes overly-enthusiastic) DIY approach does mean they open themselves up to a whole host of other problems - Google probably does know how to deploy, manage and secure Kubernetes better than anyone else, since they kinda built it. They've probably even got better stickers.

Unfortunately, setting it up is HARD. There's so many moving parts and the vaguely dodgy how-to posts on random blogs always seem to be a few versions behind - AND they feel like they get away with it by saying “Definitely probably don't do this in production, but it's totally fine to do for testing, what's the worst that could happen?*"

This talk will take you through some of the parts of the Kubernetes setup that are commonly ignored (“oh yeah we’ll definitely $100% get to that later”), or excluded from scripts you piped from curl to bash, or are pretty easy to accidentally get wrong if you didn’t know about this other thing that wasn’t made immediately obvious. If you’re a security auditor, these are your critical severity tickets. If you’re an admin, these are the things that differentiate your totally awesome cluster of orchestrated hotness from a totally awesome cluster of orchestrated hot mess. And if you’re an attacker who’s popped a shell and found themselves trapped in a container ‹strike›of emotions‹/strike›, these are the things that make you have a hard time when they’re done right.

Tue Jan 14 16:20:00 2020 at Room 7