 Hi everyone. Welcome to my talk. My name is Felix Schuster and today I'm going to talk about scalable competition computing on Kubernetes with Mabel Run. A few words about myself. I'm the CEO and co-founder of Azure Systems and we are a startup building open source software for competition computing and one of the tools that we build is Mabel Run and Mabel Run is the extension to your existing service mesh that makes your deployment a confidential deployment. So what does this mean? A couple of things. So first this means that all your data remains encrypted all the time even at runtime during processing. Next it means that you can cryptographically verify the integrity, the topology and functionality of your deployment and you get protection against very strong attackers like malicious cloud admins, malicious Kubernetes admins or even physical attackers like like data center insiders. So this sounds pretty cool right and it allows you to a couple of things. So it enables you to retrofit your existing Kubernetes deployments with top-notch security and it allows you to essentially keep the cloud provider out of your trusted computing base and use the cloud with more confidence and move more workloads to the cloud and it allows you to build exciting new applications that provably preserve the privacy of your data sources. Yeah so this possibly sounds too good to be true and so how do we do this? Obviously there is no such thing as magic so we rely on a new technology called confidential computing and in the nutshell confidential computing is all about running sensitive workloads in so-called secure enclaves and these enclaves are available on many recent server CPUs for example from Intel and these enclaves have three defining properties. So they can run arbitrary software in strong isolation and no other system component like the operating system, the hypervisor, other apps or even other hardware components can look inside the enclave or interfere with an enclave. The second important security feature is runtime encryption so everything that is stored or is running inside an enclave remains encrypted in main memory even at runtime and the final property is verifiability so you can get a certificate from your CPU that says okay hi I am a genuine Intel CPU and I'm running this piece of code in my secure enclave and this is a very strong property and we use this to build entry and verifiability for your whole cluster. So confidential computing hardware is widely available and you can get it in your favorite clouds and we for now with Malrun only support Azure but we are working on bringing it to other clouds and other hardware members. Okay so let's dig into the details so how do we create a confidential deployment? Essentially there are two steps first one you need to build confidential containers and that is fairly easy so if your app is entirely written in go then you can just use our open source go framework to just take your app and package it for an enclave. So that's done so the the last and final step is to securely mesh your services inside your your deployment at runtime and this is what Malrun takes care of and this requires a couple of steps. So first we really want to have container to to container attestation so one container running inside an enclave needs to make sure that the other container it's talking to is also running inside an enclave that's very important because otherwise it could have mock-up enclaves that could just steal secrets. Next we want to have deployment to client attestation so we want clients of our deployment to be able to verify the overall integrity and functionality of the deployment. Next we we need MTLS to not terminate inside sidecar proxies but directly inside a secure enclave because otherwise it could be intercepted by attackers and we need enclave-based secrets management so we can't rely on Kubernetes for secrets management because in our case Kubernetes is running outside enclaves so it is not part of our trusted computing base and the attackers we consider can just access the Kubernetes secret store and finally we also take care of of code updates in a secure way and from a 10,000 feet point of view this is what the workflow looks like when you install Mabura. So you start with an empty Kubernetes deployment and you do as normal you install your favorite service mesh for example Linkerd and the next thing you do is you install Mabura using the Mabura CLI and then you do a very important step and that is you define in in the file called manifest you define in JSON all the confidential computing specific aspects of your deployment and the final step is you install your app as normal and if you packaged your app with with ego then your containers will automatically contact the Mabura coordinator over secure and mutually attested TLS connections and Mabura will make sure that these containers adhere to the manifest and only if they if they do if they comply with the manifest Mabura will issue TLS credentials to these containers and will also send over the the other secrets and the next the client can come the client can establish a secure connection to you to your deployment and this connection also terminates directly inside a secure enclave so it's really end to end secure and what the client also can do is the client can get an attestation statement from the Mabura coordinator and by ex ex exon mining that statement the client can convince themself that this cluster or this deployment at tears to what is specified in this manifest and this is a very powerful feature okay so there's one app we like to use for demo purposes and it's emoji voto it's the default demo from the link of the service mesh and if you want to run this in Mabura and super simple you just package the three services using using ego you don't need to change a single line of code and you define the manifest the manifest in this case is only 130 30 lines of of jason and then you're good to go and you can just use marble run and let it take care of the rest okay and here's here's the the manifest for the emoji voto demo and the first section we define all the enclaves that are allowed to run in our deployment in this case we have here three enclaves and they are defined by by the by the by the signatures fingerprint and down here we define the the parameters for the enclaves in this case most environment variables but this could also be files for example and further down we define the secrets that live inside this deployment in this case we just have one secret which is a web search and these secrets get automatically injected into the right enclaves and marble run takes care of that right this was my quick introduction to marble run i hope you find this interesting to summarize what marble run does is it turns your existing deployment into a confidential deployment and this is super exciting because this keeps all your data encrypted at all the times even during processing and it allows you to verify the integrity and functionality of your deployment even better it protects against very strong attackers like malicious kubernetes admins malicious cloud admins or malicious datacentro workers and it enables cool new applications that preserve the privacy of your data sources next steps um check on marble run.sh for code further examples and if you have any questions feel free to to join the discord and you can find me on twitter at flxflx and yeah let's keep in touch let me know what you think and goodbye