WEBVTT 00:00.000 --> 00:09.800 So I voted on you, however, I worked with her and I actually have been following you before 00:09.800 --> 00:14.800 I worked with you as being that awesome person who did something with chickens and go, is 00:14.800 --> 00:15.800 that correct? 00:15.800 --> 00:19.200 You should enable your microphone by the way. 00:19.200 --> 00:27.040 Yes, sadly I heard there are no chickens here today, that's for the tiny go people at the 00:27.040 --> 00:32.280 last hour of the day, we have a tiny go-com, I have been told there will be no chickens 00:32.280 --> 00:36.440 but there might be fireworks which I have to forbid because of fire regulations. 00:36.440 --> 00:38.440 Here's another warning. 00:38.440 --> 00:42.640 But I'm going to let you go then you have to talk about the amazingness of something called 00:42.640 --> 00:47.640 EVBF that already has been mentioned five times a day, even without an EVBF talk. 00:47.640 --> 00:48.640 So I've lost! 00:48.640 --> 00:57.800 Hi everyone, can you hear me well? 00:57.800 --> 01:00.120 Yes, good, okay. 01:00.120 --> 01:05.760 So let's start with a quick poll, who has an Android phone here, can you raise your hand? 01:05.760 --> 01:06.760 Yeah, most of you. 01:06.760 --> 01:11.240 I mean, that was kind of obvious for the first time I guess. 01:11.240 --> 01:17.160 So let me tell you that you are running EVBF every day on your phone and without 01:17.160 --> 01:22.760 knowing it, it is there for networking and statistics about your network. 01:22.760 --> 01:29.560 You're not observe, but you might wonder if EVBF is everywhere, yes and no, so it's running 01:29.560 --> 01:36.760 on Android phone but it's mainly present today in tools in the cloud native environments. 01:36.760 --> 01:43.120 I'm Dunya Shai, and today we're going to cover what is the role of EVBF in Kubernetes 01:43.120 --> 01:48.400 and in networking using Go. 01:48.400 --> 01:50.800 How is the word without EVBF? 01:50.800 --> 01:58.200 So if you want to add a feature to a turbine application, you would probably have to 01:58.200 --> 02:04.640 probably have to ask someone from the Linux kernel development to add something in it and 02:04.640 --> 02:09.080 it can take years before this feature will reach the Linux distribution. 02:09.080 --> 02:11.760 I say years, yes. 02:11.760 --> 02:20.400 So with EVBF, you can dynamically update and write custom programs on your kernel. 02:20.400 --> 02:26.560 In fact, you just have to write an EVBF program and just a few hours, maybe even a few 02:26.560 --> 02:35.840 minutes, you are able to observe what's on your network on your kernel. 02:35.840 --> 02:37.560 Let's have an overview of EVBF. 02:37.560 --> 02:40.880 So you have an application running in the user space. 02:40.880 --> 02:46.760 So I guess most of you are developers today and go developers, yes. 02:46.760 --> 02:52.520 So you are running an application in the user space and you are doing Cisco system calls, 02:52.520 --> 02:59.640 like opening a file or allocating memory, all these things or events on the Linux kernel. 02:59.640 --> 03:03.120 And EVBF programs can be attached to this event. 03:03.120 --> 03:10.200 So each time, for example, you are opening a file and EVBF program will run automatically. 03:10.200 --> 03:18.760 But let's have a quick example of a program where you can trace when files are open. 03:18.760 --> 03:22.200 So now you are seeing C code and you're like, what is she doing? 03:22.200 --> 03:24.800 Why is it C code and a go code? 03:24.800 --> 03:30.160 Yes, you will probably have to deal with C code if you want to write EVBF programs first. 03:30.160 --> 03:32.400 So let's have a look, it's very basic. 03:32.400 --> 03:41.200 So this C program is attaching, is being attached to one trace point in the system kernel. 03:41.200 --> 03:44.320 And this C code is, is enter open at. 03:44.320 --> 03:49.440 It means that each time you are opening a file on your system or with your application, 03:49.440 --> 03:53.160 this EVBF program will run automatically. 03:53.160 --> 04:00.200 And we are just logging file opening a very simple log using a helper, VPF, right, spring 04:00.440 --> 04:05.240 like a print, a land or a print function in go. 04:05.240 --> 04:13.960 And the output when this program is logged with all the traces, file opening, 04:13.960 --> 04:15.960 and we can see here the process IDs. 04:15.960 --> 04:19.000 So there is the cat that I'm actually launching in the trace file. 04:19.000 --> 04:21.800 So this is where all the logs from the kernel are going. 04:21.800 --> 04:27.400 And system did run all, because the kernel is opening file all the time to actually run. 04:27.400 --> 04:30.840 So it's also opening file. 04:30.840 --> 04:33.320 Let's have a quick demo. 04:33.320 --> 04:37.240 Hopefully the demo will work better than the previous talk. 04:37.240 --> 04:44.520 So here I have a bunch of files, but I have my C file that I just show you. 04:44.520 --> 04:49.160 And I will show you later in this talk how you are going to attach them. 04:49.160 --> 04:52.280 But I just want to show you what it looks like. 04:52.280 --> 04:58.040 And I'm using pseudo here for one reason is that two launch EVPF 04:58.040 --> 05:01.320 program and to run them, you need specific capabilities. 05:01.320 --> 05:03.800 So that's why I'm running like that. 05:03.800 --> 05:09.880 And on this side I'm just going to do a cat of the logs. 05:09.880 --> 05:11.560 And can you see well? 05:11.560 --> 05:14.840 Yeah, it seems okay. 05:14.840 --> 05:19.720 So we are seeing all the logs from the cats here. 05:19.800 --> 05:20.600 File opening. 05:20.600 --> 05:22.920 So you can see that there are a bunch of file open. 05:22.920 --> 05:25.400 It's actually going in real time. 05:25.400 --> 05:30.040 So what you're seeing all the traces or the fine-being open in real time 05:30.040 --> 05:32.440 with this little code. 05:32.440 --> 05:34.120 So that's very powerful. 05:37.640 --> 05:39.560 I mean, I find it fascinating. 05:39.560 --> 05:41.960 I don't know what you're talking about. 05:41.960 --> 05:44.920 And this is one of many of the capabilities of EVPF. 05:44.920 --> 05:48.280 And I want to talk to you about my favorite one, which is ETP 05:48.280 --> 05:50.680 for Express Data Path. 05:50.680 --> 05:57.080 So with XDP, you can analyze and filter packets before the even 05:57.080 --> 05:59.560 rich delinux kernel network stack. 05:59.560 --> 06:05.560 So for example, if you have malicious packets that are 06:05.560 --> 06:10.600 arriving on your network, they can be dropped before 06:10.600 --> 06:11.560 it reads the kernel. 06:11.560 --> 06:13.400 It reads actually your system. 06:13.400 --> 06:15.640 So it saves CPU cycles. 06:15.640 --> 06:19.960 It can save also memory and avoid some vulnerability, 06:19.960 --> 06:22.440 vulnerability, sorry, and problems. 06:22.440 --> 06:24.200 So very powerful in XDP. 06:24.200 --> 06:27.720 And it takes the performance in general to an next level, 06:27.720 --> 06:30.920 especially in distributed systems where the requirement of performance 06:30.920 --> 06:32.440 are really high. 06:32.440 --> 06:35.640 And that's why we're talking about Kubernetes here. 06:35.640 --> 06:40.360 Kubernetes is at the foundation of cloud-native environments 06:40.360 --> 06:41.720 and distributed system. 06:41.720 --> 06:45.480 How many of you are familiar with Kubernetes and running it? 06:45.720 --> 06:49.080 OK, and not as many as I thought, honestly. 06:49.080 --> 06:50.600 That's interesting. 06:50.600 --> 06:55.320 OK, so Kubernetes is built on shared infrastructure. 06:55.320 --> 06:59.560 You have many containers running on a single host, 06:59.560 --> 07:02.280 meaning on a one kernel. 07:02.280 --> 07:06.920 Because EVPF programs are running at a kernel level, 07:06.920 --> 07:09.640 they have visibility on the entire stack. 07:09.640 --> 07:12.120 They're unlimited to one container. 07:12.120 --> 07:16.440 So all the EVPF programs can act and modify and observe 07:16.440 --> 07:21.960 what happening on all the posts across one host. 07:21.960 --> 07:25.480 And there are many use cases like networking. 07:25.480 --> 07:28.920 You can actually load balance, for example, traffic. 07:28.920 --> 07:31.960 You can do security by dropping malicious packets 07:31.960 --> 07:36.440 and forcing security or doing observability and tracing, 07:36.440 --> 07:40.920 like we just sew with the file opening. 07:41.000 --> 07:45.080 But what makes EVPF even more exciting is all the ecosystem 07:45.080 --> 07:46.200 that exists today. 07:46.200 --> 07:49.480 There is a forum of EVPF today. 07:49.480 --> 07:53.400 But there is many tools like BCC for tracing or a 07:53.400 --> 07:57.640 sealium between networking and security and pixie 07:57.640 --> 07:59.880 for observability. 07:59.880 --> 08:03.400 All these tools already exist and are using EVPF 08:03.400 --> 08:06.840 under the hood to do all this amazing thing, 08:06.840 --> 08:10.600 like tracing, profiling, monitoring, and more. 08:11.240 --> 08:14.440 Let's have a look to a quick example using sealium. 08:14.440 --> 08:17.880 So sealium is doing efficient networking. 08:17.880 --> 08:19.400 Thanks to EVPF. 08:19.400 --> 08:25.720 So in clusters, we have the posts and the most communicating. 08:25.720 --> 08:29.000 It goes through a bunch of things in the traffic, 08:29.000 --> 08:33.160 but especially goes through the chain of holes of IP tables 08:33.160 --> 08:37.800 to define where a packet come from and where it should go. 08:37.800 --> 08:39.880 And instead of doing that, 08:39.880 --> 08:43.720 sealium is using the power of EVPF by attaching 08:43.720 --> 08:47.160 these programs to specific hooks in the kernel 08:47.160 --> 08:49.320 and bypassing all this chain. 08:49.320 --> 08:55.480 So all the traffic is going to be very fast and efficient 08:55.480 --> 08:56.840 in that way. 08:56.840 --> 09:02.840 And it's again very interesting for very large distributed systems. 09:02.840 --> 09:06.440 Because you're going to be able to run a lot of requests 09:06.440 --> 09:08.120 in a few milliseconds, for example. 09:12.040 --> 09:15.800 So you have an overview of EVPF now, 09:15.800 --> 09:19.800 but you might wonder, how does it even work under the hood? 09:19.800 --> 09:22.920 So let's have a quick look, very with me. 09:22.920 --> 09:26.360 So we have first an EVPF program that is going to be compiled 09:26.360 --> 09:28.200 into bytecode. 09:28.200 --> 09:30.440 bytecode is what the kernel understands. 09:30.440 --> 09:32.440 It's 0 and 1, basically. 09:32.440 --> 09:35.800 And before you can actually attach it to system calls 09:35.800 --> 09:39.880 to hoops and tracepoints, you would have to go to one critical step, 09:39.880 --> 09:41.720 which is the very fire. 09:41.720 --> 09:45.000 And the very fire acts as a gatekeeper. 09:45.000 --> 09:48.760 It ensures that you won't crush your kernel because you're 09:48.760 --> 09:51.240 running programs that are running on your kernel. 09:51.240 --> 09:53.720 You could have a blue screen and just crush your system. 09:53.720 --> 09:58.040 And you don't want that, especially on our systems. 09:58.040 --> 10:01.640 And this very fire would check, for example, 10:01.640 --> 10:04.520 that you'll program exterminating loops 10:04.520 --> 10:08.120 or that you're not doing outside of the bone memory allocation, 10:08.120 --> 10:12.520 like very basic stuff, very interesting. 10:12.520 --> 10:16.280 When your program is approved by the very fire, 10:16.280 --> 10:19.640 you have the just-in-time compiler actually 10:19.640 --> 10:23.240 compiling it and doing some optimization, depending on your hardware. 10:23.240 --> 10:26.760 And finally, you have your program that can be attached 10:26.760 --> 10:30.040 to the system calls. 10:30.040 --> 10:33.080 Then all the processes that you are running 10:33.080 --> 10:36.040 would be able to send messages and receive them. 10:36.040 --> 10:41.000 And each time there is an event and the EEPF program is attached to, 10:41.000 --> 10:44.120 it's going to actually run automatically and dynamically. 10:44.120 --> 10:46.920 It can be socket, TCP or EEPF network device. 10:50.840 --> 10:52.680 OK, we are talking here to developers. 10:52.680 --> 10:56.680 So let's talk about development. 10:56.680 --> 11:00.680 So as I mentioned, you would have to write probably C. 11:00.680 --> 11:02.440 I know that a bit sad. 11:02.440 --> 11:04.440 But not too much. 11:04.440 --> 11:08.680 You will have a C code that you compile into object into byte code, 11:08.680 --> 11:10.600 and you can use clank for that. 11:10.600 --> 11:14.040 There are specific compiler to do it. 11:14.040 --> 11:17.960 You could write it into byte code if you like to, 11:17.960 --> 11:19.400 but I mean, no one does. 11:19.400 --> 11:21.240 It's only for the kernel. 11:21.240 --> 11:22.840 You would probably write in C. 11:22.840 --> 11:25.720 So this is the most traditional way to do it. 11:25.720 --> 11:29.400 For several reasons, but mainly the ecosystem 11:29.880 --> 11:32.440 is already built nowadays on C. 11:32.440 --> 11:34.120 There are libraries available. 11:34.120 --> 11:37.800 You can handle all the resources precisely. 11:37.800 --> 11:41.400 And if you're a cool kid, you're going to go to Rust. 11:41.400 --> 11:47.800 But so it makes the concurrency easier than C. 11:47.800 --> 11:49.480 And there is memory safety. 11:49.480 --> 11:53.960 Just you know, the ecosystem is still in maturation and evolving. 11:53.960 --> 11:55.800 There are not as many other sources, 11:55.800 --> 12:00.200 but the compiler is able to compile the EBTF program into byte code 12:00.200 --> 12:04.680 that is understand by the sub-bite kernel. 12:04.680 --> 12:06.920 And so you have your program. 12:06.920 --> 12:07.960 You're writing it. 12:07.960 --> 12:12.760 So you might wonder where I'm storing data because yeah, 12:12.760 --> 12:16.040 I can see traces, but I want to handle that at some points. 12:16.040 --> 12:21.320 Like if I'm doing, for example, counting packets 12:21.320 --> 12:23.320 going through my network. 12:23.320 --> 12:26.360 So this is where maps are coming. 12:26.360 --> 12:29.720 So maps are at the backbone of EBTF programs. 12:29.720 --> 12:34.440 This is where you will share all this data and store them. 12:34.440 --> 12:35.880 There are different type of maps. 12:35.880 --> 12:38.840 Actually, 30 of them with different types. 12:38.840 --> 12:43.640 But I mean, probably you will use hash with basic key values, 12:43.640 --> 12:46.120 but very powerful. 12:46.120 --> 12:50.280 And there are the bridge between the Linux kernel and the user space. 12:50.280 --> 12:55.160 So you would be able to write data into the map from the kernel 12:55.160 --> 12:56.840 and read it from the user space. 12:56.840 --> 13:00.360 Or you have something in the user space that you want 13:00.360 --> 13:03.880 to inject to the kernel and then be able to read it from there, 13:03.880 --> 13:05.160 you could also do. 13:05.160 --> 13:09.880 And the code in the user space is able also to load the byte code 13:09.880 --> 13:13.320 and the program. 13:13.320 --> 13:16.680 I hope it makes sense for you. 13:16.680 --> 13:17.400 Are you lost? 13:17.400 --> 13:19.400 I can feel like, no, that's OK. 13:19.400 --> 13:21.960 People are saying, yes, OK, cool. 13:21.960 --> 13:24.360 So the user space in the user space 13:24.360 --> 13:26.520 is code that you're going to run and writes. 13:26.520 --> 13:30.600 It can be written in C, but you might not write it again. 13:30.600 --> 13:33.400 You can use Python because it's more high level 13:33.400 --> 13:34.360 and their libraries. 13:34.360 --> 13:38.200 But I would recommend it for more exploration and experimentation 13:38.200 --> 13:41.080 if you want to get your hands dirty at the beginning. 13:41.080 --> 13:42.840 And of course, I'm not going to convince you. 13:42.840 --> 13:46.120 But you're already good developers. 13:46.120 --> 13:50.520 You would probably choose go for its simplicity and its performance. 13:50.520 --> 13:57.160 There are libraries that exist also today to use it with EBPS. 13:57.160 --> 13:58.760 I mentioned only three of them here. 13:58.760 --> 14:01.160 There are others that you can have a look to. 14:01.160 --> 14:06.440 But there is VBPF, go and go BBPF. 14:06.440 --> 14:09.560 There are actually based on C go. 14:09.560 --> 14:15.560 So as you may know, you don't want to use C go. 14:15.560 --> 14:21.160 But a C go and you can actually load an attached program. 14:21.160 --> 14:27.000 It's very easy to integrate with the ecosystem existing already in go. 14:27.000 --> 14:30.200 Because you might know, but in Kubernetes environment, 14:30.200 --> 14:33.000 all the tools around flood natives, most of them, 14:33.000 --> 14:36.680 or built in go, like Grafana, Prometheus, and all these tools. 14:36.680 --> 14:43.960 So that's very easy to integrate an application that you would like to deploy with that. 14:43.960 --> 14:46.280 Let's have a look to another example, the concrete one, 14:46.280 --> 14:48.680 where we are doing monitoring. 14:48.680 --> 14:53.880 So we, oh sorry, first I'm going to show you some code. 14:53.880 --> 14:56.760 Again, some C, sorry. 14:56.760 --> 14:58.520 So we have a map. 14:58.520 --> 15:03.320 So we talked about map, and I'm going to show you a concrete one. 15:03.320 --> 15:07.560 So here I'm using a map type array with a key and a value 15:07.560 --> 15:09.480 with a max entries of one. 15:09.560 --> 15:13.720 Because what I'm going to do is to store for the number of, 15:13.720 --> 15:16.920 for each time there is a packet going through my network, 15:16.920 --> 15:18.360 I'm going to increment a counter. 15:18.360 --> 15:19.880 Very basic. 15:19.880 --> 15:26.040 So my function here is just doing map hook app elements. 15:26.040 --> 15:28.600 So this is a helper that you can use. 15:28.600 --> 15:31.320 And it's going to increment this packet counter, 15:31.320 --> 15:33.160 each time there is a new packet. 15:33.160 --> 15:35.640 And because I'm attaching it to my favorite feature, 15:35.640 --> 15:37.960 do you remember XDP that I just mentioned? 15:37.960 --> 15:41.880 Each time there is a new packet, this counter is going to be incremented. 15:41.880 --> 15:42.520 OK. 15:42.520 --> 15:44.600 So I kind of like you. 15:44.600 --> 15:47.080 So I'm not going to use client directly. 15:47.080 --> 15:50.440 I'm going to use bpf to go to attach my program. 15:50.440 --> 15:53.960 It's a tool from clmvpf, and it makes the life easier 15:53.960 --> 15:54.840 as a go developer. 15:54.840 --> 15:58.760 So you have your c program, and you're going to generate 15:58.760 --> 16:01.080 go objects from that. 16:01.080 --> 16:04.200 So you can use the programs on the maps very easily in your go code 16:04.200 --> 16:06.360 and manipulate them. 16:06.360 --> 16:09.320 So I use here go generate because it's easier when you are 16:09.320 --> 16:15.000 developing and maintaining some bpf code and go code. 16:15.000 --> 16:18.360 This is the generated go objects from the comments. 16:18.360 --> 16:20.760 So this is only a sample of them. 16:20.760 --> 16:22.200 There are others. 16:22.200 --> 16:25.800 But here we have a counter objects. 16:25.800 --> 16:29.160 So inside we have a counter programs, 16:29.160 --> 16:31.320 counter maps, and counter variables. 16:31.320 --> 16:36.200 And inside the program, I have actually my program, my bpf program. 16:36.600 --> 16:40.040 Here, this trip tag, it's very important because it 16:40.040 --> 16:43.800 is the actual name of your program inside the kernel. 16:43.800 --> 16:50.120 So it makes a link between the go code and the kernel objects. 16:50.120 --> 16:51.640 And then we have the maps. 16:51.640 --> 16:54.840 So there is only one, but if you have many of them, 16:54.840 --> 16:56.600 there will appear also here. 16:56.600 --> 16:59.400 And again, this is the name of the map inside the kernel. 17:02.680 --> 17:04.520 And you have finally the main. 17:04.520 --> 17:09.480 And in the main, what you're doing is loading all these objects. 17:09.480 --> 17:11.320 By using load control objects here, 17:11.320 --> 17:15.080 this is, again, a function that has been generated by the bpf 17:15.080 --> 17:16.920 to go to. 17:16.920 --> 17:21.160 Then I just define my interface network that I'm going to use here. 17:21.160 --> 17:23.160 It's integral. 17:23.160 --> 17:26.520 And this help function not at hxdp, which 17:26.520 --> 17:31.320 is in the cilium edpf library that you can see in the imports. 17:31.320 --> 17:36.120 So I'm using in the option the programs that we just generated 17:36.120 --> 17:38.040 and the interface. 17:38.040 --> 17:42.040 And this is the way to actually attach my program, 17:42.040 --> 17:43.720 ebpf to my go code. 17:47.160 --> 17:51.080 Just one thing here, the differ, it's kind of important because when you 17:51.080 --> 17:53.960 close your program, it's going to detach your program. 17:53.960 --> 17:58.680 So you don't have it running and be attached all the time. 17:58.680 --> 18:02.040 OK, this is just the last part of the main function. 18:02.040 --> 18:05.800 It's just fetching periodically every sequence, the packet count. 18:05.800 --> 18:09.560 And we are using lookup function on the map, 18:09.560 --> 18:11.160 on the packet count. 18:11.160 --> 18:13.480 And then we just print it here. 18:13.480 --> 18:15.480 Very easy. 18:15.480 --> 18:18.360 OK, let's have a look in real time. 18:18.360 --> 18:23.960 Again, so here I have, let me show you. 18:23.960 --> 18:25.800 Can you see well again? 18:26.600 --> 18:32.200 OK, so I have my c program here that I just show you with my map. 18:32.200 --> 18:36.200 It's dp, my counter, it being incremented. 18:36.200 --> 18:39.800 I have my main that is not currently compiling because I need to 18:39.800 --> 18:41.560 generate the go objects. 18:41.560 --> 18:44.760 I had it, sorry. 18:44.760 --> 18:45.960 I had it before. 18:45.960 --> 18:48.040 So go generate. 18:48.040 --> 18:52.280 Now that I generated my objects, let's have a look to what it looks like. 18:52.280 --> 18:57.720 I have actually began in a little Indian depending on your architecture. 18:57.720 --> 19:02.760 But you can see here a bunch of things. 19:02.760 --> 19:05.880 Don't worry, what is important is to find again the objects 19:05.880 --> 19:08.200 that I just show you in the slides. 19:08.200 --> 19:13.000 And in the main, now it's compiling. 19:13.000 --> 19:16.440 We can see the load counter objects, the interface, and the attack 19:16.440 --> 19:17.880 XPP. I'm not cheating. 19:17.880 --> 19:21.160 I'm showing you the real things that I just show you. 19:21.240 --> 19:27.000 OK, so now I have this, I want to build. 19:27.000 --> 19:30.360 Let's meet. 19:30.360 --> 19:38.200 So now I have my executable here, my binary, and I'm going to launch it using 19:38.200 --> 19:40.920 against you do. 19:40.920 --> 19:42.920 Yay, it's working. 19:42.920 --> 19:47.400 So thank you. 19:47.480 --> 19:55.240 So as you can see, you're seeing the number of packets that are going through my 19:55.240 --> 19:57.320 network in real time. 19:57.320 --> 20:00.360 So we built a C programming the kernel. 20:00.360 --> 20:03.160 We wrote an application in the go code. 20:03.160 --> 20:06.840 And we retrieved all these data from the map in the kernel. 20:06.840 --> 20:09.240 And we are showing it in the user space. 20:09.240 --> 20:12.360 So that's very powerful to extract all these data from the kernel 20:12.360 --> 20:13.480 into the user space. 20:13.560 --> 20:18.520 I hope you enjoyed this demo. 20:18.520 --> 20:22.600 Now, I want to show you more concrete examples. 20:22.600 --> 20:25.800 So this is very basic things and little files that I just show you. 20:25.800 --> 20:30.520 And I want to show you in real life in a project 20:30.520 --> 20:32.360 what the code couldn't look like. 20:32.360 --> 20:35.640 And as a disclaimer, sorry for the eyes of a Latatisco people. 20:35.640 --> 20:37.480 This is not the real code from Selium. 20:37.480 --> 20:40.520 I just put some pseudocodes, so you have an idea. 20:40.520 --> 20:46.200 If you've seen some of the talks today about EVPF and STDB, 20:46.200 --> 20:49.800 you know already that it's more complicated than that. 20:49.800 --> 20:52.200 That was just a disclaimer. 20:52.200 --> 20:56.120 So Selium, it's an open-source project 20:56.120 --> 20:59.080 that is enabling network policy enforcement, 20:59.080 --> 21:02.040 doing services load balancing and more stuff. 21:02.040 --> 21:05.320 But we're going to focus on network policy today. 21:05.320 --> 21:08.200 It is using the EVPF programs to do it. 21:08.200 --> 21:09.880 And we're going to have a look. 21:09.880 --> 21:13.880 So first, we're going to declare a YAML file, 21:13.880 --> 21:19.400 and not Elvis, a YAML file to declare the Selium network policy. 21:19.400 --> 21:25.160 So what we are doing here is just saying that all the inputs 21:25.160 --> 21:26.920 with the labels matching back-end. 21:26.920 --> 21:32.360 So endpoint is a pod for the people that doesn't know it's a resource. 21:32.360 --> 21:38.360 And sorry, I'm going to say it again. 21:38.360 --> 21:42.600 So we have a pod that has labels matching back-end, 21:42.600 --> 21:45.960 and all the traffic coming from the pods 21:45.960 --> 21:49.400 with the labels matching front-end are allowed. 21:49.400 --> 21:53.400 Otherwise, all the traffic coming from external, 21:53.400 --> 21:56.920 I don't know, and you would like to contact the back-end, 21:56.920 --> 21:58.120 cannot. 21:58.120 --> 22:00.440 I mean, this is a very common use case. 22:00.440 --> 22:03.480 You don't want anyone to communicate with your back-end, 22:03.480 --> 22:05.080 and only the front-end. 22:05.080 --> 22:08.920 So in the code, what it looks like. 22:08.920 --> 22:13.400 So I will have something called an endpoint 22:13.400 --> 22:16.040 with an ID, labels, and identity. 22:16.040 --> 22:20.120 Because in Selium, all the pod's other resources 22:20.120 --> 22:23.000 are transforming to identity. 22:23.000 --> 22:25.800 An identity is a set of labels. 22:25.800 --> 22:28.440 And here, I have two end points. 22:28.440 --> 22:33.480 So two identities with the front-end and the back-end. 22:33.480 --> 22:35.160 So this is my set of labels. 22:35.160 --> 22:37.800 I, for the sake of this example, I put only one, 22:37.800 --> 22:39.960 but you could have several of them. 22:39.960 --> 22:42.920 And then you have a policy with a source identity, 22:42.920 --> 22:45.720 and it's one, and the destination identity, 22:45.720 --> 22:47.640 which is two, the front-end and the back-end. 22:47.640 --> 22:48.840 And we say that is allowed. 22:48.840 --> 22:49.640 It's true. 22:49.640 --> 22:52.040 You could say that it's denied and safe-falls. 22:52.040 --> 22:56.120 It depends of what you are dealing with. 22:56.120 --> 22:59.880 Then we have in the EBPF map code, 22:59.880 --> 23:04.920 all the policies that are stored in a map. 23:04.920 --> 23:07.480 So we can do it from the GoCode. 23:07.480 --> 23:10.440 So you define a map in the kernel program, 23:10.440 --> 23:13.000 in the EBPF program, and from the GoCode, 23:13.000 --> 23:16.040 you are injecting dynamically all these policies 23:16.040 --> 23:20.920 that you are defining in the YAML configuration 23:20.920 --> 23:23.400 and deploying live on your cluster. 23:23.400 --> 23:26.920 So again, everything is dynamic in real time. 23:26.920 --> 23:29.800 So for example, if you want to mitigate a vulnerability, 23:29.800 --> 23:33.320 you could actually deploy a configuration 23:33.320 --> 23:37.080 and a telemetric policy in real time. 23:37.080 --> 23:40.920 And finally, you enforce these policies in the EBPF program 23:40.920 --> 23:46.200 by saying, if this source identity to this destination is allowed, 23:46.200 --> 23:49.800 in that case, I'll let the back-end paths 23:49.800 --> 23:54.040 otherwise we drop it. 23:54.040 --> 23:56.440 I hope I sparkled some curiosity, 23:56.440 --> 24:00.680 and you'll learn a lot about EBPF. 24:00.680 --> 24:03.720 Either you want to contribute to EBPF and Selium, 24:03.720 --> 24:08.040 or just add some little EBPF in your day-to-day life. 24:08.040 --> 24:11.000 I would recommend to go to the lab from ISOValant 24:11.000 --> 24:12.360 to EBPF getting started. 24:12.360 --> 24:14.520 This is where I started. 24:14.520 --> 24:16.120 You don't have to set up an environment. 24:16.120 --> 24:18.680 You just pop a cluster for you with all the dependencies 24:18.680 --> 24:19.400 that you need. 24:19.400 --> 24:21.400 So that's very cool. 24:21.400 --> 24:23.720 And all the examples that I show you 24:23.720 --> 24:25.720 are available on my repository. 24:25.720 --> 24:28.280 And I would love to connect, get feedback, 24:28.280 --> 24:30.840 have your point of view about EBPF. 24:30.840 --> 24:32.360 There is an EBPF room. 24:32.360 --> 24:35.560 So if your career is next year, you can go there. 24:35.560 --> 24:37.600 And thank you so much. 24:37.600 --> 24:38.600 applause.