 Thank you. Hello everyone. So who here has heard of EBPF? Quite a lot of hands. Excellent. So EBPF is a hot topic in CloudNative for very good reason. It's a wonderful platform for building network, observability and security tooling. EBPF lets us detect and react to events from within the kernel. Wether those events are triggered by something happening in user space or events that happen in the kernel like a network packet reaching some point in the network stack. And the beauty of this in CloudNative is that because EBPF programs run in the kernel, we only have to instrument nodes rather than instrumenting each individual workload. All of the applications that run on a virtual machine share one same kernel and a process whether it's running inside a container in a pod or even directly on the host is using that same kernel and whenever it wants to do anything interesting and potentially security relevant, it's going to have to ask for assistance from the kernel. So if we have EBPF programs in the kernel we can detect and even affect what's happening in any user space application or process. And if an attacker manages to run malicious code on your machine, EBPF tooling will be just as aware of it as any other process. There are several projects in the CNCF today and sub-projects that leverage EBPF for connectivity and observability and security. You just heard about FileCode for example. And today I want to talk about the power of taking the events that these kinds of tools generate and using them to create visualisations that can help us solve security specific problems. So let's leave Seattle and go and visit an organisation that's actually been using cloud native tooling for a very long time. The empire is a huge user of open source software. It adopted Kubernetes a long, long time ago. And if we look at what's currently running around Endor we can see there are a few tie fighters milling about. There are a couple of instances of well we run the death start with high availability obviously. The empire uses Cillium for network connectivity. So we can look at the network flow logs that are generated by Cillium's Hubble component and we can see all the traffic that's flowing in the spacecraft around Endor. The information that goes into these Hubble logs is collected by Cillium's EBPF programmes that are inserted into various points in the network stack. And because Cillium is aware of Kubernetes identities the network logs don't show us IP addresses, they show us which pods are involved in each network flow. And we can also see details of what's happening at layer 7. So this is giving us lots of really great information and lots of really useful details but the stormtrooper who's in charge of security on the death star knows that it would be a lot easier to understand what's happening and which spacecraft are communicating with each other if that was presented in some kind of visual pictorial form. Here's the Cillium Hubble UI which takes all those individual network flow logs and builds up a picture of which services are communicating in the Endor namespace. Everything seems okay, we can see some TIE fighters are talking to the death star, talking to the Star Wars API, totally makes sense and also to Disney because I think they're negotiating contracts on some kind of reality TV series that they're going to film on the death star. And our security stormtrooper wants to put some network policy in place. He wants to know that only empire traffic is going to be able to flow in this namespace but network policy can be a bit fiddly and he doesn't want to get it wrong, he doesn't want to upset the generals but this stormtrooper knows that Hubble doesn't just generate network flows, it also generates Prometheus metrics and in particular he's interested in the Prometheus metrics that are generated about network policy verdicts so whenever a policy decision is made whether to drop or forward or redirect a packet that generates metrics so our stormtrooper has set up a Grafana security dashboard and right now there's nothing on it because we don't have any policies in place yet so there are no policy verdicts to show but let's start by putting in place an allow all policy so that every single packet will generate a policy event so the allow all policy is going to apply to all the spacecraft in Endor and it's going to allow those craft to receive packets that's ingress traffic from anywhere and it's going to allow sending packets that's e-west traffic to anywhere and when we put that policy in place once things have settled down we'll see a pretty steady state of we'll just look at ingress traffic for now that's being generated by the TIE fighters around Endor all of that traffic is matching on policy type so on the left hand side we can see all the packets are being forwarded and on the right hand side we can see they're all matching an all policy type so now our security stormtroopers going to start with the ingress traffic and the introduce of policy that's going to make sure that traffic can only flow to the death star if it comes from Empire spacecraft and when he applies that policy we can see traffic continues to be successfully forwarded so the left hand side stays the same but on the right hand side we can see that the traffic is now being matched by a layer three specific policy rather than that allow all policy and if we remove the ingress rules from that allow all policy everything is going to basically stay the same because all our expected traffic is matching that Endor specific policy so that's great but we're hearing a rumour that there are some Empire spacecraft in another star system and they're trying to send us some messages from Hoth and if we check the security dashboard we can see that those packets are being dropped this is a problem because some of this traffic from Hoth is coming from an Empire star destroyer and we're going to be in big trouble if that traffic doesn't get through so our security stormtrooper adjusts the policy and allows traffic to come from anywhere provided it comes from an Empire spacecraft something that's labeled with the organization of Empire and things improve we see fewer packets being dropped and we can see that the star destroyer traffic is being forwarded correctly but we're still blocking traffic from some X-wing fighters that are being flown by the Rebel Alliance and also from some ship known as the Millennium Falcon whatever that is so this all seems good but we have heard another rumour that there's a spy there's some kind of rebel android thing that's stowed away and is trying to exfiltrate the plans to the death star fortunately our stormtrooper team are running with Cilliam's Tetragon runtime detection tool and the tetragon logs are also hooked up into the security dashboard and if we check out the executables pane of the security dashboard we can see some highly suspicious activity right there at the top highlighted in red we can see that somebody is running netcat this is not expected but we can see exactly which pod did it when it happened so we're going to be easily able to root out the spy and throw them into the trash compactor so i've shown here some dashboards set up in Grafana that the Empire's security team have built using logs coming from Cilliam and Hubble and Tetragon and Prometheus metrics coming from Hubble and Cilliam but there are plenty of other combinations of tools and visualizations that you can use to solve other kinds of security problems with cloud native tooling here are a few other examples that i've found so here's a visualization of detecting sequel injections using pixie it's another ebpf based project in the CNCF you just heard about falco here's a pie chart showing falco rule violations here's a more complex dashboard that's been built on tetragon showing information about access to sensitive files and all of these tools are able to pull this really detailed information and tie it back to Kubernetes identities thanks to the power of ebpf and the ability to write tooling that's both very finely grained and highly performant so ebpf tools can generate these streams of really rich contextualized events in the form of logs and metrics and traces and as humans we can make much more sense of that data if we can visualize it and then we can use it to debug network policy like you store our stormtrooper security team doing we can use it to spot unexpected access to particularly sensitive files we can use it to spot data being exfiltrated we can use it to see unexpected binaries being run anywhere in our cluster we can even identify privilege escalations using ebpf all of these things can help us solve real security problems and Darth Vader is so impressed he's actually thinking of having the empire join the CNCF as an end-user organisation thank you very much