Extending Kubernetes with WebAssembly
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
López, Rafael Fernández
WebAssembly is a portable binary instruction format that was originally created with the browser as the main execution runtime. However, during the last years, WebAssembly is finding its way also outside of the browser because of the many benefits it provides like portability, security and flexibility. We think WebAssembly can be leveraged by Kubernetes in many ways. This short session will focus on how WebAssembly can be used to write Kubernetes admission policies. We will show an open source Kubernetes Dynamic admission controller that uses policies written in WebAssembly to validate and mutate the requests made against the Kubernetes API server.
 Hello everyone, my name is Rafael Fernández Lopez and I'm a Senior Software Engineer at SUSE. And today we are going to talk about extending QnRs with WebAssembly. So first the following is WebAssembly. It is a binary instruction format. It allows us to build once and run everywhere. It is a standalone. It allows us to store metadata inside of the binary. And it is a target in multiple languages. So we can use the language and the toolchain that we are reading now on Lof. So we are going to extend QnRs with it. But how exactly? So one of the main components of QnRs is the API server. The API server reads and stores information into a distributed key value store called HCD. So we as users reach out to the API server. Other components might as well, whether they are internal or external to the cluster. So let's look at the internals of the API server. Every time a request comes into the API server, it gets authenticated and authorized. Then this object inside this request could be mutated. Then it gets validated against the schema of the object. And then it gets validated. If everything is fine, it will get stored into HCD. So what you see here as webhooks is a concept of QnRs called the dynamic admission control. And so we are able to register in which type of operations, in which kind of objects we are interested, and in which webhooks we want to target with them. So the API server will perform an HTTP request every time a request like that comes and will call to the right webhooks in order to mutate or validate the request. And so we thought, what if we could use WebAssembly to write this small amount of code that is able to mutate or validate code, validate requests, instead of Kubernetes. And so Qwarding was born. With Qwarding, we are able to define policies. And so these policies are able to mutate or validate requests. So how to execute policies? Instead of Kubernetes, you deploy the Qwarding controller. And by defining policies that target different kind of resources, different operations, you are able to either mutate, accept or reject. And so policies get executed inside policy servers. By default, there is only one policy server, but you can create as many policy servers as you want. And so you can target different policy servers from within different policies. So you might want to create one policy server per tenant. This is completely up to you. And so this is how it works inside of Kubernetes. You can also run policies outside of Kubernetes. So you can check if they behave as you expect, whether you are developing a new policy or you are using one that you found. And so you can run KWC, you have available the KWC TLD CLI tool that you can run inside your laptop, your desktop, so you can run policies offline without the need of Kubernetes. So running is only part of the problem. The other part of the problem is distributing these policies. And so you are probably used right now to OCI registries because you are using OCI registries to distribute container images already. So the good news is that you can use this same OCI registry to also distribute policies as long as the OCI registry allows the OCI artifacts. And so now how do you serve policies? We have created the policy hub in where you can find different policies so you can discover them and use them as you need. And now let's look for a short demo on how to run policies. And here we have a policy that will reject services that are of type log balancer. So we are going to pull this policy, you can think of this as podman pool and podman images, but just for policies with KWC TLD. And you can see now that we get the list, just the policy that we just pulled. We can inspect the policy, remember that this is inside of the binary, this information that flies with the policy itself. And we can see a request that should be allowed. In this case we are creating a service of type cluster IP. So this should be fine. Let's run that with KWC TLD and we see that this was allowed. So this request would be allowed if we deployed this on top of the cluster. Let's look at another request. In this case it tries to create a load balancer service type and this gets rejected by the policy. You get that the message comes from the policy itself. You can see more commands for KWC TLD. You can inspect policies, you can annotate them, you can pull, you can push to an OCA artifact. You can also verify them by using SIGSTORE. So you have different options over there. So join us. Everything is being done in the open. So you can go to our GitHub org. You will also have a Twitter account. You can go to the Q&A. This is like the Fisial 1 or the Renser users one. And we also have official websites. So you can look into that. So that's all from me. Thank you for joining me today and have anything else. Enjoy the rest of the event. So everyone, welcome to the Q&A for Extending Kubernetes with WebAssembly. I see there are currently no questions. Rafa, maybe you can tell us more about this. Yeah, absolutely. So one of the things that I wanted to also add to what I have already said is that you can write policies in the languages that you want. Right now we have SDK. And by SDK, I mean like a library that you can use to write the policy. It's super simple. In Rust, Swift and Go. In this case, you have to use TinyGo as the compiler because the official Go compiler from Google doesn't allow you to build a standalone WebAssembly module. And so you have Rust, Swift and Go. And we also have another policy, for example, within the assembly script. We don't have an SDK for that. But if you are eager to write it, you are absolutely welcome. And also besides that, you could also write basically policies in a language that you can use with WAPiC. And so this is what we are using in order to call policies from the policy server on KWC.tl. And so with this WAPiC procedure call, you write basically your policy. And so you could, for example, write also policies in SIG if you were interested. We don't have SDK for that either. But yeah. And besides that, we also have plans for extending QBorden. So you can also have background checks. Like for example, I have something created in the cluster. Everything is fine. It passed all the policies. Then I deployed a new policy afterwards. And this is actually kind of breaking, I have resources that are already persisted, but they are now breaking the new policies. So you have background checking in order to tell you about this. And also you have another, we are working on another model in which before you actually deploy policies into the cluster in production, you are able to see if they were about to break something that is not yet on the cluster. So for example, I could deploy a policy in this mode. That is just like a notifying mode. We don't have an info yet. But the idea is that before I deploy this policy in production that could potentially break stuff. I deployed it in this model, maybe notify, I don't know. And then you see what it would have rejected. It won't reject, but you see what it would have rejected or what would it have mutated. So you have this information in your logs and you are able to deploy policies in this mode without the need of actually running them like in production, taking actions or rejecting, accepting or mutating requests. And besides that, if you also want to create policies, you are absolutely welcome. We have about 22 policies right now in the Q-word and hub. This is where we serve policies. People can learn about new ones and deploy new ones, publish new ones. So you can use that. So take a look at that and create policies if you are missing something over there. And with that, I think we are right out of time. So thank you, everyone, and enjoy the rest of Fuzzland. Thanks, Rafa. Thank you. Thank you.
 Hello everyone, my name is Rafael Fernández Lopez and I'm a Senior Software Engineer at  SUSE.  And today we are going to talk about extending QnRs with WebAssembly.  So first the following is WebAssembly.  It is a binary instruction format.  It allows us to build once and run everywhere.  It is a standalone.  It allows us to store metadata inside of the binary.  And it is a target in multiple languages.  So we can use the language and the toolchain that we are reading now on Lof.  So we are going to extend QnRs with it.  But how exactly?  So one of the main components of QnRs is the API server.  The API server reads and stores information into a distributed key value store called  HCD.  So we as users reach out to the API server.  Other components might as well, whether they are internal or external to the cluster.  So let's look at the internals of the API server.  Every time a request comes into the API server, it gets authenticated and authorized.  Then this object inside this request could be mutated.  Then it gets validated against the schema of the object.  And then it gets validated.  If everything is fine, it will get stored into HCD.  So what you see here as webhooks is a concept of QnRs called the dynamic admission control.  And so we are able to register in which type of operations, in which kind of objects we  are interested, and in which webhooks we want to target with them.  So the API server will perform an HTTP request every time a request like that comes and will  call to the right webhooks in order to mutate or validate the request.  And so we thought, what if we could use WebAssembly to write this small amount of code that is  able to mutate or validate code, validate requests, instead of Kubernetes.  And so Qwarding was born.  With Qwarding, we are able to define policies.  And so these policies are able to mutate or validate requests.  So how to execute policies?  Instead of Kubernetes, you deploy the Qwarding controller.  And by defining policies that target different kind of resources, different operations, you  are able to either mutate, accept or reject.  And so policies get executed inside policy servers.  By default, there is only one policy server, but you can create as many policy servers as  you want.  And so you can target different policy servers from within different policies.  So you might want to create one policy server per tenant.  This is completely up to you.  And so this is how it works inside of Kubernetes.  You can also run policies outside of Kubernetes.  So you can check if they behave as you expect, whether you are developing a new policy or  you are using one that you found.  And so you can run KWC, you have available the KWC TLD CLI tool that you can run inside  your laptop, your desktop, so you can run policies offline without the need of Kubernetes.  So running is only part of the problem.  The other part of the problem is distributing these policies.  And so you are probably used right now to OCI registries because you are using OCI registries  to distribute container images already.  So the good news is that you can use this same OCI registry to also distribute policies  as long as the OCI registry allows the OCI artifacts.  And so now how do you serve policies?  We have created the policy hub in where you can find different policies so you can discover  them and use them as you need.  And now let's look for a short demo on how to run policies.  And here we have a policy that will reject services that are of type log balancer.  So we are going to pull this policy, you can think of this as podman pool and podman images,  but just for policies with KWC TLD.  And you can see now that we get the list, just the policy that we just pulled.  We can inspect the policy, remember that this is inside of the binary, this information  that flies with the policy itself.  And we can see a request that should be allowed.  In this case we are creating a service of type cluster IP.  So this should be fine.  Let's run that with KWC TLD and we see that this was allowed.  So this request would be allowed if we deployed this on top of the cluster.  Let's look at another request.  In this case it tries to create a load balancer service type and this gets rejected by the  policy.  You get that the message comes from the policy itself.  You can see more commands for KWC TLD.  You can inspect policies, you can annotate them, you can pull, you can push to an OCA  artifact.  You can also verify them by using SIGSTORE.  So you have different options over there.  So join us.  Everything is being done in the open.  So you can go to our GitHub org.  You will also have a Twitter account.  You can go to the Q&A.  This is like the Fisial 1 or the Renser users one.  And we also have official websites.  So you can look into that.  So that's all from me.  Thank you for joining me today and have anything else.  Enjoy the rest of the event.  So everyone, welcome to the Q&A for Extending Kubernetes with WebAssembly.  I see there are currently no questions.  Rafa, maybe you can tell us more about this.  Yeah, absolutely.  So one of the things that I wanted to also add to what I have already said is that you  can write policies in the languages that you want.  Right now we have SDK.  And by SDK, I mean like a library that you can use to write the policy.  It's super simple.  In Rust, Swift and Go.  In this case, you have to use TinyGo as the compiler because the official Go compiler from  Google doesn't allow you to build a standalone WebAssembly module.  And so you have Rust, Swift and Go.  And we also have another policy, for example, within the assembly script.  We don't have an SDK for that.  But if you are eager to write it, you are absolutely welcome.  And also besides that, you could also write basically policies in a language that you  can use with WAPiC.  And so this is what we are using in order to call policies from the policy server on KWC.tl.  And so with this WAPiC procedure call, you write basically your policy.  And so you could, for example, write also policies in SIG if you were interested.  We don't have SDK for that either.  But yeah.  And besides that, we also have plans for extending QBorden.  So you can also have background checks.  Like for example, I have something created in the cluster.  Everything is fine.  It passed all the policies.  Then I deployed a new policy afterwards.  And this is actually kind of breaking, I have resources that are already persisted, but  they are now breaking the new policies.  So you have background checking in order to tell you about this.  And also you have another, we are working on another model in which before you actually  deploy policies into the cluster in production, you are able to see if they were about to  break something that is not yet on the cluster.  So for example, I could deploy a policy in this mode.  That is just like a notifying mode.  We don't have an info yet.  But the idea is that before I deploy this policy in production that could potentially  break stuff.  I deployed it in this model, maybe notify, I don't know.  And then you see what it would have rejected.  It won't reject, but you see what it would have rejected or what would it have mutated.  So you have this information in your logs and you are able to deploy policies in this  mode without the need of actually running them like in production, taking actions or  rejecting, accepting or mutating requests.  And besides that, if you also want to create policies, you are absolutely welcome.  We have about 22 policies right now in the Q-word and hub.  This is where we serve policies.  People can learn about new ones and deploy new ones, publish new ones.  So you can use that.  So take a look at that and create policies if you are missing something over there.  And with that, I think we are right out of time.  So thank you, everyone, and enjoy the rest of Fuzzland.  Thanks, Rafa.  Thank you.  Thank you.
container_k8s_webassembly_0_3047.png container_k8s_webassembly_3048_3107.png container_k8s_webassembly_3108_4571.png container_k8s_webassembly_4572_4667.png container_k8s_webassembly_4668_5195.png container_k8s_webassembly_5196_5243.png container_k8s_webassembly_5244_5639.png container_k8s_webassembly_5640_6359.png container_k8s_webassembly_6360_6515.png container_k8s_webassembly_6516_6671.png container_k8s_webassembly_6672_6959.png container_k8s_webassembly_6960_7775.png container_k8s_webassembly_7776_12827.png container_k8s_webassembly_12828_13509.png