Runtime Security for Regulated Teams: Falco, eBPF & Cilium

A pod called payments passes every admission policy from last week's stream. It isn't privileged, it has its owner labels, a pinned image from an approved registry, resource limits, no host mounts. It's legitimately compliant. Then someone opens a shell in it, reads the password file, drops a binary that was never in the image and walks over to the HR database. No admission webhook was ever going to see any of that. Admission control asks one question, once: should this exist? Runtime security asks the other one, for as long as the thing runs: what is it doing? Most teams I walk into have a good answer to the first and no answer at all to the second, and most control frameworks want both. This is a live build on a real cluster. Cilium is the network, Falco is watching the syscalls, and I attack the same pod eight different ways to show which tool notices and which one stops it. Nothing is a mock-up: the slides read the rules and identities straight out of the running cluster. The through-line: Falco detects but never blocks. Cilium blocks, and Hubble records every verdict with both ends named by pod. They answer different questions, and anyone selling you one box that does both is selling you two things in a box. Chapters 0:00 Intro 3:05 Who I am, and the half last week left out 5:41 The problem: a pod that passes every policy 9:37 Should this exist, vs what is it doing 10:39 The regulated angle 11:38 eBPF in plain English 14:20 Falco: eBPF on syscalls 15:40 Falco detects, it does not block 16:52 Cilium: policy by identity, not IP address 18:20 Cilium blocks, and Hubble records it 19:56 One attack, two answers 22:09 The demo: eight ways to attack one pod 22:56 #0 The legitimate call 24:01 #1 A shell in the container 25:16 #2 Reading the shadow file 26:18 #3 A binary that was never in the image 27:30 #4 A custom rule for your own estate 28:28 #5 Calling out to the internet 29:35 #6 Lateral movement to the HR database 31:05 #7 The Kubernetes API, and an untuned rule 32:59 Network policy in audit mode 34:48 Enforce: the HR database call is dropped 36:22 Why Falco went quiet after enforcement 38:01 The results in one table 38:40 Detection vs prevention 39:08 What happens when each agent dies 40:27 Nobody turns on default deny at 4pm on a Friday 41:33 What this buys a regulated team 43:00 Where this falls short 45:19 Where to start on Monday 46:15 Back where we started 47:08 The two minute check to do this afternoon 47:36 Book a discovery call The one thing worth doing this afternoon: pick your busiest namespace and run kubectl get netpol. If the answer is zero, and for a lot of people it will be, every pod in there can reach every other pod and everything else on your network right now. Last week's livestream, on policy as code with OPA Gatekeeper and Kyverno, referenced throughout this one: https://youtu.be/Cz_Bgg8wedM Falco: https://falco.org Cilium: https://cilium.io Tom Barber: https://linkedin.com/in/tombarber Want this done properly for your own cluster? What you can detect today, what can reach what, which five rules are worth turning on, and what you put in front of an assessor when they ask. That is what a discovery call is for. It is free, and it comes to me rather than to a form. https://concepttocloud.com or tom@concepttocloud.com Concept To Cloud builds production data and compliance platforms for regulated, data-heavy organisations. #kubernetes #falco #cilium #ebpf #runtimesecurity #devsecops