Marblerun now supports Occlum — even more confidential computing at scale

Hey there 👋 If you’ve found you way to this blog, you’re probably aware of confidential computing and its open-source landscape. In this context, we’ll today talk about the recent support for Occlum-based workloads we added to our Marblerun framework. But before we dive into the details, let’s recap what both projects are about.

What is Occlum?

Occlum is a memory-safe, multi-process library OS for Intel SGX. In short, it is simplifying the programming of apps in secure enclaves. Those of you who have tried to transfer your existing code to enclaves know how long it can take to adapt hundreds of lines of code. Occlum enables users to run their programs without modification inside enclaves just with a few commands. If you are interested in learning more about this topic and the project, check out their website for further information.

What is Marblerun?

From our previous blog posts, you might remember that Marblerun enables DevOps engineers to deploy, scale and verify SGX-based apps on Kubernetes. In the cloud-native world, apps are typically split up into microservices that fulfil certain tasks. To control and secure the communication between microservices, service meshes like Istio or Linkerd are used. Marblerun augments these service meshes with features required in the context of confidential computing. It communicates parameters securely to your services and manages different types of secrets for them. It can also make your deployments end-to-end verifiable and end-to-end encrypted (in the confidential computing sense). Marblerun is not inherently tied to Kubernetes: some folks also like to use Marblerun standalone to provision and manage enclaves.

Marblerun + Occlum

Now that we have introduced Marblerun and Occlum, two obvious questions arise: Why should we combine the two? And how do we do this? The first one should be easy to answer by now: Marblerun is used to manage, scale and verify confidential apps and Occlum makes it easier to implement them. It’s a match! The second one requires some more examination, so let’s dive right in.

Marblerun generally requires that some small boilerplate code called “premain” is included in your enclaved app. The premain is executed automatically once your app is run, e.g., as a service on Kubernetes. The premain automatically contacts Marblerun’s coordinator. The coordinator verifies the service using SGX remote attestation, before issuing a deployment-internal TLS certificate to it. The coordinator also sends over all the service-specific parameters (i.e., environment variables, file systems, and command-line arguments) and secrets. The premain uses these to set up the desired execution environment inside the enclave and then starts your actual app.

How to configure Occlum

Marblerun can automatically inject the premain code into apps built with our EGo framework. For Occlum-based apps, we need to explicitly include the premain in the enclave image, e.g., in /bin, and set it as the sole entrypoint of the app in the Occlum config file:

How to configure Marblerun

Next, we need to tell the premain where to find our actual executable of our app in the Occlum image. We do this securely via the Marblerun manifest: The premain expects the path of the executable (e.g. “/bin/hello”), as its first command-line argument. Accordingly the Marblerun manifest for a simple Occlum-based “hello world” looks like the following:

Next steps

Ready to build, run, and scale your Occlum services with Marblerun? Check out the full documentation on building Occlum-based services or jump right in with a “hello world” example. Let us know what you think.