Hi everybody, I'm Fabio Castelli from SUSE. I'm really honored and excited to be here with you today, and I'm also super happy to be sharing the stage with your colleague of mine, Rafael. Hello everyone, I'm really glad to be here and thank you for coming. Yeah, thanks for coming. So we are here today to talk about how we think we can improve the process of writing Kubernetes policies. And before we start drilling down how we came to this conclusion, we would like to start with a really open question, which is how do you handle security?  We do realize this is a really open topic. This is a wide topic with many facets and we could be there sitting and talking for hours about how to build secure container images, how to harden container runtimes, how to produce networking policies. What we want to talk about instead is how our back policies, as many of you have already realized, are not enough, they're great, awesome, but there is always a need to bring in extra checks, extra policies on top of Kubernetes. So how can we do that in a more comfortable way? Why is that in a more comfortable way? Well, security is a big topic and it's hard to grasp all of it, but there was a research done last year during the late of 2020, which has some really interesting insights. So these are the key takeaways for us from this research. So 66% of the users who joined this survey do not feel comfortable enough with their security story. The thing we should be doing more. And while there is a positive trend instead of many companies about DevSecOps, which is not a fancy term anymore, there are people, companies investing, growing to fill this role. However, despite all of that, only 16% of the participant to this survey are actually implementing security policies as code instead of a Kubernetes cluster. Why that? We think that this boils down to major pain of Kubernetes and security Kubernetes, generally speaking, not just writing policies, but they do play a part in that, a big part. So first of all, there is a lack of skills. Not many people inside of the company have the right set of skills to fulfill this task of writing policies as code. And there aren't many people available on the market either. And why that? I think that's because of the second point, because there is a really steep learning curve when it comes to Kubernetes, generally speaking, when it comes to security, but also when it comes to writing policies. As a matter of fact, Boff Raff and I tried to do that. We wanted to improve our clusters. We wanted to help our customers in doing that. And so we were advocating for the process of writing policies as code. And we sat down, we said, let's write some of them to show how this can be done to users, to customers whatsoever. And oh man, we felt the pain. We realized that there is indeed a really steep learning curve. It takes a lot of time to grasp either this new programming languages that are not really programming languages or understand how to tame these big YAML files but policies as code. And this is something that requires time. And yes, there are examples out there. There is documentation, even good documentation. But as soon as you try to do something which is not trivial, something more convoluted than you're on your own. And this is where I, at least I personally felt frustrated many times because I knew exactly what I had to write to implement some check, but I was struggling to translate these concepts that were clear in my mind into these policies as code frameworks. And I kept saying, it would take me a heartbeat to implement this check using any of the programming languages I ever used in my career. I could write that in Rust, I could write that in Go, I could write that in JavaScript, it would be really easy but I'm here and I'm feeling stuck because I can translate that. And we reached out to some friends, to some customers who were already doing policies as code because they wanted to do that. They wanted to be conscious and do their good job in securing their workloads and clusters. And we found that there were basically two approaches. There were some people who basically gave up and said, I need to have policies as code but I don't have the competencies, the knowledge inside of the company, I don't have time to grow that. So I just resort to some external consultants. I did quite some searching and I finally managed to find some consultants who can write policies as code. And so I go to them, I explain the full picture, the full context and then after some time they come back to me with some policy that I don't understand honestly, but I just trust them and I deploy that and anytime however I need to do some change I have always to go back to them and restart all this conversation cycle which is taking away time and money as well. On the other end, there were others who said, let's grow this set of skills in-house. So let's take some folks instead of organization and let them learn how to do that. And they succeeded in that, but unfortunately this is not scaling because they ended up having one, two folks that are capable of writing and most important of all reviewing policies because as in the same way we're talking about policies as code and in the same way as you are reviewing your code you're also meant to be, I think you are meant to review the policies you're deploying and these are security related things so you should be really understanding what is being deployed and enforced inside of your cluster. So going back to these folks they have two maybe three people that can write policies inside of the whole organization and now all the policy tasks are going through these poor folks that are the bottleneck, everything is low done, they feel overloaded because they also have other tasks to accomplish. So this is not scaling at all. And on top of that, some of those people are not yet into GitOps. Some of them want to enter also this new topic but they don't have the time right now to do that. And so they were struggling in finding a way to distribute all these policies across all the different Kubernetes cluster they have to manage. So Rafa and I started thinking and said, okay, what can we do to improve the situation? What can we do to help other people, to help ourselves, to help our customers? So we sat down and we came up with this wish list. First of all, we said, there is a lot of knowledge we already have and people inside of the organization they have already a vast amount of people with experience in writing code. So these developers should feel productive as well when writing policy as code. They should be able to leverage all the existing knowledge they have, the tool sets they have, all the coding practices that they are already following day by day with code reviews, with test-driven development, with style checks, all of that should be reusable also when it comes to write policy as code. And you might argue that you can already do that. You can go ahead and you can write a Kubernetes webbook endpoint and do that. That's true, but you know, you have to keep repeating a lot of code instead of each one of these webbook endpoints. And there is a lot of duplication, there is a lot of boilerplate, there is a lot of understanding how to set up all of that. What we want to have is to allow people to focus only on the relevant part of this job. They have to focus on this tiny portion of business logic, which is the one doing the mutation, doing the validation of the request, and then just end over this policy to a platform that can run it for them with no worries. Last but not least, we want also to have a way for operators to find these policies, a way for offers to share these policies, to summarize that, we want to lower the barrier to write policies, to review policies, really important to think, to build policies, share them, and finally to run them. So Raph and I started to think about how to do that, and we created this project that we think can help you with all of that. This project is called Cubewarden. We started working on that some months ago. It's a Kubernetes policy engine which is taking care of all the paperwork for Kubernetes for you. So under the hood, we are using webbooks as well, but you don't have to spend time fingering all of that out. Well, this is not new. I mean, other are doing that. The main difference of Cubewarden is in how the policies are written. Polices in our case are real code. It's a code that is built into WebAssembly. So I don't know how many of you are familiar with WebAssembly. So let's just do a quick overview about that. So as soon as we started to look into WebAssembly, we definitely felt in love with that. It's amazing. It's something which is not just for the browser. Many people think that WebAssembly is something that has been designed for the browser. That's not a thing anymore. WebAssembly is growing out of the browser use case. And I don't know if you noticed, but as a matter of fact, this year for the first time for this CubeCon, there is a co-hosted conference track about WebAssembly, only WebAssembly. So there is a lot of interest, there is a lot of traction. Many programming languages are already supporting WebAssembly as a build target, and many more are joining the ranks. So you can, there are really high chances that you can really pick your favorite programming language and build WebAssembly modules out of it. What are WebAssembly modules? Well, WebAssembly modules are basically the result of the compilation of your code into WebAssembly. It's a binary artifact which is portable, and this is pretty interesting. It's something that, for example, allows you to write a Q-word in policy as code on your shiny new Apple M1 machine, build it, push it, and then deploy it in production on top of the Kubernetes cluster that is running on Linux on x86. These WebAssembly modules are really build ones and run everywhere. And last but not least, WebAssembly is secured by design.  WebAssembly was meant to be run inside of a browser which has a huge attack surface. And so there were a lot of technical decision, design decision that lead to the creation of a secure environment where WebAssembly can run. So there is a sandbox that is running your WebAssembly code, which has really few privileges. It has a memory design that is secure. And I think this is pretty important. I mean, we're talking about this project in the security space, so it should be secure as well. So now all of that is cool. At least I hope you find it as cool as we do, but you might be wondering, how this is going to make a difference? How could Gordon is going to simplify my life as an operator or as someone who wants to write policy as code without investing too much time in that? Well, I will leave Rafa to cover that. Thank you, Flavio. So as Flavio hinted already, you might see that we have like two main personas here. So let's go with the first one. This is the cluster administrator. And the message that we have for you is that we have you. The thing about policies, as Flavio mentioned, is that they are binary blobs and they are isolated when executing, but the important part about distribution is that they are binary blobs, absolute binary blobs that don't change with the processor architecture with anything else. So you have to distribute them somehow in order for your policy server to pull them from somewhere. And the way that we do have to distribute that with Qboarden is container registries, something that you are already operating, something that you are already securing for your workflows, for whatever you are running on your Kubernetes cluster. So basically what you need is a container image registry that supports the OCI artifact specification. So if you have that, then you can just push your artifacts as you were pushing a container image and then you can pull from them or our policy server can pull from them. Also, distribution is only part of the program as a processor administrator. If I am to download some policy developed by either an author party or someone within my organization, I might want to try whether it will perform as I expect or will do the right things as I expect on the production cluster. I don't want it to reject things that shouldn't be rejected. I don't want it to accept a request that shouldn't be accepted and so on. And the idea is that we have a way to super easily test a policy against different settings and input or requests from Kubernetes in an offline, completely offline way. So you can introduce these on your existing workflows. So you make sure that all the behaviors are the ones that you expect and nothing more. Also, the important part here being so strict in terms of security is that we run these policies in a safe Wasson environment. So a safe Wasson environment by definition, nowadays it's running in let's say in a sandbox and the idea is that it's completely isolated from the host system. The memory, for example, is completely isolated. Basically everything is isolated from the host system. So it's a very safe place to run arbitrary workloads. In the end, policies are arbitrary programs, right? So we want them to be safely run as safe as possible. And running or following this logic, we wanted the policy server that is in the end what runs your policies to write it in Rust. Rust, as you might know, is a relatively new language program by the Mozilla Foundation and the idea is that it's a safe programming language. So the idea is, it's a memory safe and it has a lot of good properties. And we wanted to use this one, Rust, in order to write the policy server. And for the authors, the main idea is that we want you to feel productive. We want you to use your favorite programming language or a programming language that you are comfortable with. We want you to build once and run everywhere. As we have said several times around this talk, this time is for real. This is a motto that we know has been around for years now, but this time is for real. Do you build your artifact? And then this will run. I don't care where you build it. With architecture, you build that on, on which lead seats running beneath it. We don't care about anything like that.  And also we wanted a way, a simple way to write mutation policies, not only validating once. So if you want to default some things, if you want to do some, any kind of mutation on your resources, it's super easy and simple for you to do so. And of course, for you to feel productive, we want you to reuse your knowledge. If you use libraries, TDD, cold int in CICD systems or pipelines, we want you to reuse all that. So that's the main idea. And what is the current status of the project? So right now, everything is on alpha quality and stability. We have a number of sample policies, but also for running them, we have custom resources, Kubernetes custom resource and a controller to manage policies. So you don't need to do all the paperwork on Kubernetes like creating the validating webhook configuration or the mutating webhook configuration. The controller will take care of that for you. You only create your custom resources and basically everything will happen automatically. And then it's possible to run validating and mutating policies. Also we have a prototype of context-aware policies. So sometimes just looking at the request is not enough in order to take a decision whether you should accept or reject the policy. Sometimes you need to take a look at the cluster context. Let's say what other resources exist in the cluster in order to take a decision. So I don't allow you to duplicate this host on this ingress if I have another ingress already defined with this host, for example. It's just an example, but context-aware policies is something in general that is very interesting. Also policy SDKs we have for guest, for writing your policy guests. We have two languages right now, Rust and Go, but more should come with time. So right now this is the current status with the SDKs. And we also have the policy help. As Flavia said, a really important part of this is how to share this as a policy author or as operator, how can I find what policies are out there that I can consume and that I can enforce in my organization. So here you have a snapshot of the policy hub. The idea is to improve it. And basically this is just a common place for policy authors are for operators to share policies and to discover policies. And the idea is we want to build something together. So it's a very fresh project, CubeGuarding. There's a lot of things to do in all kind of parts of the project in old France. We want feedback about design, about architecture, about security, we want to help shape the policy SDKs. Right now we have two, we would like feedback on that if they are enough, how to improve them or get more SDKs done for more languages. And the idea is that we want you to come back through your achievements. If you brought new policies, anything you do, we are interested in knowing because in some sense you are going to shape the future of the project. So we are interested in that. And how can you do that? So you can find us on the GitHub organization called CubeGuarding. We also have a main website called cubeguarding.io and the policy hub that you can find over there. So everything that you can find is public, all the design and the development is done in public. So you are free to join and we actually encourage you to join us. And with that, that's everything. We hope you enjoyed the talk. Thank you for joining and enjoy the rest of the event. And you are now Q&A. So these are your questions. Thanks a lot for joining and we look forward to interact with you. Thanks.