 Okay, let's get started. Thank you everyone for joining us today for today's CNCF webinar. Critical Dev and SecOps considerations for multi-cloud Kubernetes. My name is Jerry Fallon and I will be moderating today's webinar. We'd like to welcome our presenters today, Slovan Puget, Senior Product Manager of Carbon and Cloud Native Solutions at Nutanix and Loris Dijani, CTO and founder of SISTED. Just a few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen. Please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of the Code of Conduct. Please be respectful of your fellow participants and presenters. Please note that the recording and slides will be posted later today to the CNCF webinar page at cncf.io slash webinars. With that, I'll hand it over to our presenters for today's webinar. Thank you, thank you, Jerry. And so let's get started. So yeah, my name is Slovan Puget. I'm the, as Jerry said, Senior Product Manager at Nutanix working on Kubernetes or Kubernetes Distribution, namely Carbon Clusters. I have a personal background more as an end user. It's probably my first time in a software development world. So I come more from the technology side of things, more of the practitioner side. And today I have the great pleasure and honor to co-present with Loris from CSD. So Loris, take it from there. Thank you. Yes, my name is Loris DeGioanni. I'm CTO and founder of CSD. CSD is my second company. My first company was called Case Technologies and was the company behind the Warshark Network Analyzer. So I've been in open source and security and visibility for essentially my whole career. Recently, I was also one of the people that created Falco, which is currently a CNCF incubating project. So I still enjoy being active with the community and in particular with CNCF. Today we're going to talk about DevSecOps. We're going to talk about security. We're going to talk about cloud-native. But let's start by the high-level trend, right? And the high-level trend definitely is toward software. Software is becoming more and more important in every industry, every vertical, every enterprise nowadays is an enterprise software. Definitely there are trends that are like influencing the old world, the old planet, IoT, artificial intelligence are examples of these trends. And in every industry, even the more classical industries, even like brick-and-mortar industries that have to do with the physical world, nowadays software really is the differentiator and what determines the success or failure of a company of a business in the long term. And software is becoming more and more containers. Software is becoming more and more orchestrated, modern microservice-based applications. Let's talk about containers first of all. I've been following this industry essentially since the beginning, since when Docker started the container revolution around six or seven years ago. And it was very interesting to notice how containers initially were perceived just as a lighter form and more lightweight form of virtualization, right? So they were considered alternative to virtual machines. They quickly, thanks to the fact that the packaging of a container is well-known and transportable and can be used to run containers in multiple places, they quickly became the basis of continuous integration of CICD and really they sort of revolution the way we all do CICD. But the real power, the real value of containers comes from their ability to be the building block of orchestration and therefore to be in conjunction with modern orchestration frameworks like Kubernetes, really the new paradigm in how we write applications, how we deploy these applications, how we run these applications in productions and just essentially the new way of writing software. Now, if we look at these a little bit more from like the security point of view and from the ecosystem point of view, one of the things that definitely I find the most exciting about containers is the ecosystem, especially if we look at the ecosystem around the cloud native, around CNCF, even just for security, we can see that there are a lot of powerful components that come essentially from the community. Istio for service mesh, tools like Falco that I'm personally involved with for runtime protection of containerized infrastructures and the ability to essentially detect threads and zero day vulnerabilities as your infrastructure is running and your applications are running on top of this infrastructure. Policies, like centralized policies with open policy agents, OPA, network policies in conjunction with networking frameworks like Calico for just networking and layer three segmentation. Image scanning with Encore and they all like CI CD kind of protection. Admission controllers to be able to maybe in conjunction with tools like COPA to control what goes in your cluster and runtime like filtering and protection like post security policies of second profiles. These to me looks like a really rich powerful ecosystem that is all of the components or most of the components that you were used to like find from essentially fragmented commercial vendors, it's essentially all in the same place and all in the same ecosystem. And this is very powerful. The reason why Open is powerful in my opinion or at least one of the reasons is that at this point we can create consistencies, we can create mutual benefits, we can create harmonization among these different tools and make them essentially work together in a stack which is very powerful. It means less vendor lock-in, but it also means much more value and much more innovation in the ecosystem and for the final users. Also, this means potentially more complexity. If you look at all of these pieces, I was saying Falco is the one that I'm really involved with on a day-to-day basis and deploying Falco is not easy. Managing Falco is not easy because Kubernetes is not easy and orchestrating applications is not easy. So deploying Falco means that you need to essentially to push this kind of runtime protection on your whole cluster and having it constantly running requires a decent amount of expertise. And this is just one of the components. So each of the components like Kisteo or I don't know, OPA require certain amount of skills and just making them work together requires non-negligible amount of context. From this point of view when we're talking about complexity, typically one metaphor that people have used for cloud is the metaphor of pets and cattle, right? Traditionally, before the cloud, before virtualization, before things like, I don't know, AWS, we used to treat our servers as pets. Each of them was special to us. Each of them deserved our focus and our care. Each of them, we needed to make sure it was healthy and that it was happy. And then cloud came and in cloud, essentially we don't worry too much about the single instance anymore. Typically we have many of them behind the load balancer. They can grow, they can decrease and we try to design our infrastructure so that we don't care about the single one but we care about them as a group. And this is a well-known metaphor. It didn't invent it, you know? What I think is that we are the next iteration of this metaphor. Now we're going from cattle to locusts. Why? Because now our entity of computing, our unit for our applications for our services is the container. Containers are small. They can move from one place to another pretty fast because there's an orchestrator like Kubernetes that can take them and they can just essentially move them to different places or reorganize them based on the workload and generate a quick expansion or reduction in the number of containers. There's many of them. It's harder to keep track of them. They not only cannot be approached on a one-by-one basis but it's almost like counterproductive. And by the way, if you are not careful about what you do with them, they can be very dangerous and you can get in trouble. So welcome to the era of locusts. And of course, as we move to locusts, there are problems that we have to solve. It's harder to understand what locusts do and it's definitely potentially harder to secure them. Again, if we go back to the world of pets, this is my very artistic representation of the classic multi-pr application. You can have a cache in front of a web server that then talks to the database that stores the state. Nothing magic here. Nowadays, the same architecture looks a little bit more like something like what we have in this slide. Here, we have multiple computing nodes. So each gray box here in this slide is a node, typically a piece of physical hardware that is running our containers or a virtual machine or a cloud instance. This is sort of, it doesn't really matter too much. And then we have containers running on top of these nodes. And for simplicity, I put four containers in each node and I coded them based on the service they belong to. Before we had the database server and the web server and so on. Now we typically have services, deployments that sit behind a lot balancer or DNS names and they are implemented by multiple containers that work together to implement those services. And then of course, these can talk to each other in arbitrary ways. So it's pretty clear by just flipping the slides and compare these two pictures where the challenges and the complexity come from. Complexities and challenges also require and involve approaching these with a new mindset. One thing that is pretty clear is that it's not only a matter of just having containers and having Kubernetes and having orchestration and having microservices, but the whole stack, the whole ecosystem needs to evolve not only in terms of new functionality like in the slide before where I was showing the new projects that are part of the ecosystem, but each of these projects are here, because each of these projects are a way of rethinking, reimagining a core piece of functionality that was implemented in a certain way and just need to be rethought with a blank sheet of paper when you go from this model to this model. Otherwise it won't work. Segmentation, like your traditional firewall that was, you were putting it in three or four pieces before. Now you need to just think about how you do it. And that's how tools like for example, Calico or service meshes and so on are appealing for us. Runtime security, again, I work on Falco. So that was when I started Falco, I was inspired by the previous generation of tools, like for example, Snort, like a Selenux and so on, but it was pretty clear that it was impossible to apply these tools in a natural way to the world of Locusts. And that's essentially why we started Falco and that's why we're working on it and we're really taking a different approach with Falco. Containers in particular have the additional challenge that they tend to be like more isolated, which is great, but also a little bit more opaque and challenging in terms of visibility, right? So not only we have a new paradigm, but we also have a new paradigm that from one point of view provides better independence and isolation and structure in our applications, but at the same time creates challenges in terms of visibility. And because of these challenges, very often people say containers are less secure. So one of the drawbacks of containers, one of the drawbacks of the new cloud paradigm is that they are less secure than our previous generation of applications. Well, I argue it's the opposite. It's actually containers and Kubernetes are more secure. For sure, they're way more secure. It's a matter of managing the complexity, managing the different pieces and components that I was mentioning before and architecting them together in a stack that covers the life cycle. In particular, when looking at the security for Kubernetes, security for cloud native and security for containers, I like to approach these with a three tier approach. Build, run and respond. Build is the CI CD phase of building and creating and bringing to production cloud native applications. And building means essentially going from the code, the editor of a developer that creates the components of an application to essentially bringing that application to the production stage and to run it in the production environment. During build, we want to make sure that early on, we take advantage of the shift left in security. In particular, it's important to take care of scanning vulnerabilities, scanning our code, scanning container images, and essentially being able to block at different places in the CI CD, the application, that when it contains issues and security concerns and being able to give the proper feedback to the developers so that their workflow is helped by this and not hampered by this. The application then goes into runtime and here essentially it's running and runtime is the place where the application delivers essentially the value to the users, but it's also subject to attacks from the external world. So runtime security is very important. Tools like Falco are very important here to essentially being able to detect and protect applications as they run. Segmentation and micro segmentation is very important in this phase. Vulnerability reporting, security monitoring, which is a new area, is extremely important as well because it's part of a feedback loop that allows essentially to maintain and manage the application as it runs, but also to inform essentially the stages of the CI CD pipeline. A very important area that is very often forgotten when crafting the proper approach to container security is the respond area. This is one of the areas that changes the most with containerization and with Kubernetes because traditionally incident response, forensics, auditing and this kind of stuff was done by instrumenting and adding components to each of our computing units. When the unit is the host or the virtual machine, you have a full operating system running on these entities and if something happens, essentially, very often what you do is you SSH into this unit and you can start essentially your forensics, you can start understanding the blessed values of something detected. How do you do that with a container? First of all, by the time you receive a red light, that something has been detected by the green runtime part, your stuff is pretty much, your container is gone. And even if it's still there, containers are designed to be minimal and very small. So you don't have inside the tools that you need. So approaching in the proper way, the respond phase is definitely part of this tech and it's one of the important ways to make containers more secure. And of course, then there's compliance which spends essentially everything because when you want to be compliant, PCI, we are all delivering SAS applications nowadays and our users are demanding that their data is safe, that our applications are compliant. When you do that, essentially, that needs to spend build, run, and respond. So that's how I approach this. And yes, even I would love to see your perspective and your point of view on this. Thank you, Loris. So yeah, I like this approach. It's essentially, as you said, it's securing end-to-end the lifecycle of the application. You absolutely have to look at every single step of the lifecycle of this application from the moment it's thought of from the developers all the way to going to the IT operation and operationalizing that application. So going from dev to production and you need to make it secure which ties us back to our theme which is dev sec ops. We need to have all those three components working together. And in your environment, in your slide, there's one thing that I like is focusing on runtime because guess what? All of the tools that you mentioned, whether it's your CI CD pipeline, your registry, your alerting, your responding, all of those things are themselves application. All of them have their own lifecycle. All of them are sitting on some pieces of infrastructure somewhere. So I'm going to give all of you guys that are attending and yourself, Loris, as well, the benefit of the doubt and say that you know all of that and I know you know all of that, Loris. So you've probably secured all of your application very well. My question to you is, if you only secure the top of your stack, that application, whole secure is the whole stack. And what I mean by that is the rest of that stack, the infrastructure behind it, the storage, the who is running that stack because as we all know, the security of our application is only as effective as its weakest link. And so if you've done your homework, if you've put your application in the most secure possible way out in the world, but the team responsible to own and operate that application isn't following those same practices, that can be a real issue, right? So my answer is the locus, I love that analogy, but I think there's one element on the first that can do even more damage and that's a human. So I'm really sorry, but the human error can be even worse than any swarm of locus. We have tons of example, I mean, if you open any of the websites and specialize the news these days and even some of the just popular news media, all of them have example of human errors that cause cascades of issues that cause a lot of lost revenue, maybe even loss of life. We just had a recent example today with rent somewhere that did a lot of damage and even killed someone. I mean, we don't wanna be in those situations so you need to consider the whole stack. And even if you secure your application, the human can always be a problem. And the reason being most of you know that and what I'm saying is probably just evidence for a lot of you guys, but it's in infrastructure world, in most enterprise infrastructure world, there is still a lot of human involved. There's still a lot of repetitive tasks. And what happens, we all know that as apps developers as DevOps guys, we've learned that. What happens when you have a lot of repetitive tasks, it gets boring very quickly. And what does a human brain do when it gets boring? It creates errors. It's unwillingly making errors in creating and in doing those tasks. So if you have perfectly automated the top of your stack, but your infrastructure isn't up to par, then you are probably sitting, setting yourself up for a disaster in the future. And so let's take a deep look at the security down the stack which is the next slide on that deck. Can you make your platform more secure? I believe you can. And you can by treating essentially your infrastructure more or less like you would treat any other application. So I'm just stating the obvious here. Many of you, most of you probably are already using tools like Chef, Puppet and Sible, whatever is your automation tool of choice. However, that's something that maybe your infrastructure guys are using for your apps, but not for everything. Did you even have that conversation with them? Because again, if your infrastructure is not secure, the blast radius of having for example, a gaping hole in your virtualization management plane, it means that your app is very secure in your VM, but the bad guy already is seeing all of your VM, including yours. So right there is the problem. There's also a way of, as Loris mentioned, public cloud providers have evolved a lot or way of consuming infrastructure. So sometimes falsely, we think that by going with a public cloud provider with AWS or Azure or GCP or whomever, we aren't secure by default. No, you're not. All those guys, what they do is they provide you infrastructure at your own risk. It doesn't replace and it doesn't cover any of the risk that you're taking by running those application. If anything, and that's more of a personal opinion on that, if anything, you give up a lot of control on that infrastructure, which means that you don't necessarily have the tools available to you to run those checks, to run those audits, to make sure that your infrastructure elements are correctly configured. But the reality is, as much as I would love to say everybody is using and consuming infrastructure as cloud, in enterprise world, that's far from being the reality. Most enterprises out there are still using traditional storage, networking, virtualization, the so-called three-tier infrastructure stack. And all of those things usually are silos. And what happen if one of those silos is compromised, then the whole stack is compromised. So the next slide talks a bit about the security through the cloud native, throughout your cloud native journey. One element, one very key element in the DevSecOps trio is the security team. Dev and Ops guys, these days we've learned to try and work together. We've patched things up sometimes with more or less success, but we've, and I come from the IT Ops. I have 10 years in that industry in financial sector. So it's something that's very close to me. And I trained as a developer. And so I was doing something like Dev Ops for years, even before that train came in. And so for me it was just business as usual, but I sort of opened my eyes to the fact that that's not how people are doing it. And so I'm very happy to see that Dev and Ops have now starting to have that discussion and that coherence of their action. But there's a third party in that relationship, in the DevSecOps. It's the security team. And for better or worse, in many enterprise that I'm involved with and I talk to, I realized very quickly that even if the Dev and Ops team have sort of bonded together, usually they've bonded together against that third team. And if you dive into that, why is that? It's because they don't speak the same language, but they have the same need. The security team, if you just listen for a few minutes and you translate their concern, you'll see that they are very, very close to what we call now this Dev Ops mentality. So for example, the security team will come with this question of, I want auditability. And Laurie's covered that very well in the world of Dev Ops, like with containers being ephemeral, how do you audit what's happening? So you need those tools. You need those accountability. And you guys already have that. It's just a matter of exposing that to that security team. They don't wanna look over your shoulder to everything that you do, but they have their own accountability of those things. They usually want to see automation because automation means it's reproducible. They can know from the get go what's going to happen. They want those logs. They want the automation. Guess what? Your tools are already doing that. It's just you're not using the same language as the security team. Next thing that they want, they want simple processes. Why? Remember that human error story? If you have complex processes, if you have complexity in your stack, Laurie explained that very well at the beginning of having added complexity by adding a lot of tools that require a lot of knowledge, specialized knowledge around that. That's something that the security team gets scared of because then there's a scarcity of skills. There's specialized skills that may or may not be there when you need it to audit something or something like that. So instead of those things, by having microservices, something that we know in the DevOps world and in this cloud native world to be the unit of computing that we practice, a microservices does one thing and one thing only. So it's very simple. It's as simple as it can be. The rest, the tools around it are automating that, are automating those processes. So it's not human. But if we need to, we can go and look at what this process is doing. The third pillar of security team is they want no disruption. And what I mean by no disruption is no disruption to the business. They're accountable for the business. So if there's any breach, if there's any downtime, they get called because that's their responsibility. They are the first responder for that in many cases these days. And so by having non-disruptive Kubernetes and operating system upgrades and infrastructure upgrades by having a real modern infrastructure stack that you can treat as an app, it means that you can provide that level of compliance and discussion with those SEC teams and really start embedding them into those DevSecOps trio. The next part is around essentially the same idea of security through the cloud native journey. If you start bringing together those ops, those Dev, and as we saw those security practitioners, if you start bringing all of those people together, then you start realizing that we look for the same thing and we are just talking about it differently. So don't fear your security team. Don't push them away. Try and bring them with you, especially because as we'll see on that last slide and I promise I'm stopping there, that's the next step on that cloud native journey is the security when it comes to multi-cloud. Most of you are probably already consuming at least one cloud provider or some form of infrastructure in your environment. The next logical piece that everybody is anticipating is that you'll start consuming multiple pieces of infrastructure and tying those together and weaving them together. But if it was already complex to secure one infrastructure, think about all those things, the same complexity diagram that Loris was showing for an app and those containers interacting between compute nodes, you start to have the same thing at a macro level between clouds, between cloud providers, between infrastructures, between technologies that drive your infrastructure. So you're adding a lot of complexity even before you start starting the first app. And so what if instead of having those layers upon layers upon layers of complexity, what if your infrastructure was an app like any other? Who would you go about securing your app in that environment? That's my question to you guys. That's my send-off and your homework if you want around that. It's really think about who you are going to secure that and build together that DevSecOps team because that's the way forward. Do we have any questions? Thank you both for a wonderful presentation. As you stated earlier, as always, please feel free to drop in questions into the Q&A box at the bottom of your screen and we'll get to as many as we can at the end. Do you want to add anything, Loris, to? No, I mean, just essentially just as a wrap up, it really feels like the right approach involves I was showing right to left, right? And from one point of view, going into the build phase by shifting left, but also being able to take care of runtime and the respond phase. But it's almost a bi-dimensional chart here, right? Because it's right to left, but it's also up and down in our stack, right? Because each of the components that are in the left to right, then are based on a stack that as you were saying, here can be on-prem, can be in the cloud, but more often is and will be more and more in a combination of different multiple places. So there's no right and left security if the underlying foundation is not secure enough. So the right approach really feels like a combination of making sure and focus when protecting applications in the two-dimensions of a two-dimensional chart. Absolutely. I see one question coming up. So the question, and I really read it out loud, is what do you feel about security of cloud infrastructure moving towards on-prem, example, Azure Arc or AWS Outpost? So I can take that one if you want, but. Yeah, I will let you answer that. Just clearly these is a trend that I see more and more just the approach of cloud vendors of starting essentially offering or Google Anthos, all of these start offering essentially a consistent or trying to offer a consistent experience that spans from the traditional cloud and goes more into the data center. This is like definitely a business kind of trend for the cloud providers. Clearly, as cloud grows, the data center remains important and the competition in the data center becomes a very important factor in the competition. So business-wise, this makes sense, but I feel like at least conceptually it makes sense also architecture-wise because bringing consistency definitely allows to create better infrastructures and from the security point of view, which is the angle we come from, definitely consistency helps security, right? Now the question is, I find the two trends that are a little bit competing. One is this one and the other one is what we have on the slide, which is segmentation and fragmentation of clouds and with the increased competitiveness of clouds, you very often want to look at operating in multiple clouds because of financial considerations, technical considerations because there's a service that is very strong in Google Cloud and another one that is very strong in Azure and so on. So this is sort of an orthogonal trend and this to me speaks more to having a proper abstraction layer that allows you to run stuff, everything. So one trend is take one of these and bring them in your own data center and there are benefits related to that. Another trend is like ignore this layer and think it as a slightly higher layer and make Kubernetes the common language and make containers in the Docker format, the common execution format and then you can maybe abstract and maybe you don't care too much what's running here. Which trend is better and which one will win in the long term? I'm still not completely sure about because they both have valid values that they're bringing to the table and Sylvain, feel free to add your thoughts here. Absolutely, so I agree with everything you said. I would just want to add one dimension that we haven't mentioned because we focused more on the technical aspect of security and the other aspect of security is the legal one. It's the laws of the states of the governance of datas, that kind of aspect who are too often ignored by developers and more of a consideration or preoccupation from the security guys who have oftentimes their, from whom this is the job to make sure they're abiding by all those laws. And so to get back to the question of security of cloud infrastructure moving toward on-prem, I believe one aspect outside of the obvious business angle that you mentioned is this notion of sovereignty of data of where is my data? Where is my app? Who has access to it? What can those person do with it? And again, it goes to not only the human error but the human oversight of who has access to those data. And so I don't know if you're in Switzerland, for example, you may not want your data to be accessible by someone else. You may want to be the Switzerland of data. It might be your new way of storing, after storing money in banks, you may want to store data in data vault and have sovereignty over that. So the trend from, and I believe the trend is also the same we've seen in this industry for much longer than cloud. We started with very centralized monolithic system where everything was in one place. And then we moved to micro PC and Open and the world of X86 with distributed computing everywhere. And then we started to have cloud providers where once again, all the resources, all the compute that many of us are using was once again getting very quickly centralized in a very single places or at least under a very few umbrellas. And now we see the cycle starts expanding again. We are seeing the trend of those compute going back out because for example, in the list of use cases that you mentioned at the very beginning for IoT, for AI, you don't necessarily want or have the luxury of going all the way to a cloud. So having those, the way of consuming a cloud very locally and having a cloud like feeling of an experience, but getting that on premise and being able to apply the same treatment and as you very rightly said, being able to abstract the differences of where those infrastructure are sitting is I believe a very integral part of making your infrastructure more secure. Do we have other questions? Jerry, do we have any questions? No waiting at this moment. Everyone feel free to leave your questions in the Q&A box and we'll get to as many as we can. We have 10 more minutes. Anyone at all? Don't be shy, we're here. What are the best multi-cloud tools to move from one public cloud to another with a proper security audit? So, and again, Cévain, I don't know if you want to start with this one, otherwise I will give you a quick shot on that. Tools to do multi-cloud while providing proper security audit. I think in these days and age you need to remember a few things and we'll go back to the technical side for once. All those cloud providers have different format. So when you're talking about, for example, just moving data is already a challenge. You need a tool that you're going to be able to convert from let's say AMI to whatever storage your destination infrastructure use. So for example, VMDK or whatever. So you need, already there is some complexity in that. Whatever you choose, you need to make it an automated tool. So if the tool doesn't provide automation because we are DevOps and because we are now taking a DevOps approach to infrastructure and as I said, we're considering infrastructure as a nap like any other. All those tools that we use that provide those kind of security. I mean, shameless plug for Nutanix on that. We have a tool called Move who does just that. So we have, for example, that capability. We have orchestrated that. But we do it in a way where every single action that is taken from cloning a disk to converting it to pouring down the machine or everything like that, everything is audited. So you get a trace of every single action who does what at what time and every single action that has been taken. However, what you do not wanna do is reintroduce the human factor into the equation. So you need to build that automation. And the reality is when it comes to infrastructure, it's still an area that's very lacking in terms of automated tools for a lot of those actions. And there's still a lot of development and a lot of movement in that area. Not necessarily as much as I wish there would be because I see the developer sides of the house getting all the new shiny toys and they get all that automation. But the infrared guys are left wanting. And so there is opportunities for that. So companies like myself with Nutanix, we have, as I said, tools that can do that. And pretty much every vendor, cloud vendor has at least a tool to get you in. The issue is how do you go out? And that's also something you need to realize, especially in that multi-cloud era that we were mentioning at the end. So Loris, you probably have something to add. No, I just, I agree with you. I just want to add a thought that might seem trivial, but it's not completely trivial, which is if you want to be multi-cloud and at the same time have good consistency for security, use Kubernetes. And when you use Kubernetes, if you remember, let me share this slide, right? With the tools in this slide, the stack. We were talking about, in my part of the presentation, I was talking about the stack, and the fact that the stack is open. When you use Kubernetes, you are essentially guaranteed that the projects that you're reading on this slide will be supported actively by every cloud provider. You are guaranteed that the cloud providers will not only make sure they are well integrated, but they will probably be active contributors to same of these, to several of these. Again, I come from Falco. I'm active in the ecosystem. We're constantly working with cloud providers to give you an example. Just yesterday, we have a working group, essentially to a Falco support Fargate in AWS, which is an interesting environment. And we're working together with Amazon to get the best possible experience to our users. So the beauty of the Kubernetes stack, and the reason why I very often use operating system of the cloud to describe Kubernetes is that it's an opinionated way to run your applications in a way that you can do in your data center, you can do it completely by yourself, or you can do with different degrees of essentially support from the cloud provider. So instead of mentioning something specific or specific like approaches or use cases or vendors, I just give the generic answer, but there's more depth into this answer than just use Kubernetes than what you would see. Essentially put the proper abstraction layer in place. Pretty much, use the proper operating system. Okay, I think we have time for one more question. So if anybody wants to get in the last minute question, now's the time to do so. Anyone at all? No takers. Okay, well, no have any takers. We'll wrap up today's webinar. I wanna thank our presenters today for a wonderful presentation. Thank you all for attending. Have a wonderful weekend everyone. Thank you very much. Thank you, Loris. Have a good weekend. You as well. Bye.