Cloud Native Computing Foundation Online Programs, 24 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Meets Confidential Computing by Moritz Eckert | OC3 2022

Description

Thanks for another great OC3! Check out Constellation, the first confidential orchestration platform: https://www.edgeless.systems/products/constellation/

Welcome to OC3 on demand! The Open Confidential Computing Conference (OC3) is the online conference for all topics related to Confidential Computing.

In this video, Moritz Eckert from Edgeless Systems maps the design space for confidential Kubernetes and shows the latest corresponding developments from Edgeless Systems.

Subscribe for more interesting talks: https://www.youtube.com/channel/UCOOInN0sCv6icUesisYIDeA

Follow Edgeless Systems:
GitHub: https://github.com/edgelesssys
Website: https://www.edgeless.systems/
Twitter: https://twitter.com/edgelesssystems
LinkedIn: https://www.linkedin.com/company/edgeless-systems
Blog: https://medium.com/edgelesssystems

A

I want to start with a short background on kubernetes, just giving you a brief introduction for those that are not that familiar with the terms. So you know what I'm talking about. So kubernetes is a cloud orchestration framework. A kubernetes cluster consists of a central piece called the control plane.

A

It has all the logic that is necessary for aux trading code and data in the cloud, and then it's joined by a bunch of nodes, essentially you're computing resources that have a small agent called the cubelet that takes care of communicating with the control plane, communicating with the other nodes, and if you, as a user, want to deploy workloads to the cloud using kubernetes. You talk to the control plane, you define a deployment and then kubernetes takes care of scheduling this to one of those computing nodes.

A

So an application in kubernetes is typically called a pot. That's the smallest unit that kubernetes is handling and a part essentially consists of one or multiple containers and some definitions on what resources they need, what configurations they have and your application can be split into one or multiple parts. Again, each of them containing one or multiple containers and then resources as, for example, storage, that in kubernetes is called volumes.

A

So you build and define your application, um and then you tell kubernetes to deploy it as parts and, as I said, they are scheduled on these so-called nodes. A node is essentially in most cases a virtual machine containing the small agent piece called the cubelet and a container runtime.

A

So you uh so the the pod can can run the containers and if we go into a higher overview ice, as I said, we have this note in the middle that consists of the your workloads, the parts we have, the control plane. That has all the logic for orchestrating uh scheduling um and and keeping the state of your application and on the right-hand side, we have a bunch of cloud services that your cloud provider of choice is offering you as additional resources that kubernetes can use, for example, networking load, balancing cloud storage as a user.

A

I have an interface called the api server. I connect most cases using the kubernetes cli tool called cubectl. I connect to this api server and then from there on. I deploy my workloads and because this is a public service most of this stuff, I don't even have access to like the control plane. If I'm using a managed kubernetes, it's completely managed and controlled by the cloud provider similar to the cloud services and in a public space. We all know there are a lot of insecurities.

A

There are threats, there's a lot of things. I have to trust. So the question I like to address here is: how can we leverage confidential computing to protect all parts of the system to make it a fully confidential kubernetes?

A

And I see two use cases here. The first one is isolating existing deployments, basically, securing existing applications in the cloud making them uh running them in a private space, and the second one is deploying new applications that have built in privacy that are designed for running in confidential computing that leverage confidential computing to create new types of use, cases that were not possible so far, so let's take a look at how we can protect the workloads and the data in kubernetes and the first concept I'd like to show you is called the enclave concept.

A

Most of you might be familiar with this. um The most common example is intel sgx.

A

The idea is essentially that you repackage your applications into process-based enclaves, you containerize them and you can then deploy them as part of your parts, and this is very simple in kubernetes, all you have to do is use a device driver to enable kubernetes to use those sgx capabilities, and this isolates your individual workloads, very small tcb. You only have to trust your own code essentially and, of course, sjx or any other process-based enclave, but this is not really lift and shift. You have to repackage rebuild your application, maybe change even code.

A

So a very um similar approach in terms of protection, but very different technology in use, is the confidential container concept, and in that case, instead of using process-based enclaves, we use confidential virtual machines and instead of using a container runtime to run the containers in a pot, you run a new confidential vm for every part in your kubernetes cluster.

A

So you could have nasa virtualization or bare metal machines for your nodes and, from that point on, you, boot up a new confidential vm for each part and run your containers inside there and I'm not going to go into more detail here, because the next upcoming talks are going to be exactly about this concept about confidential containers.

A

What both of these concepts share is they are focusing on individual workload protection. So what we have now is on our kubernetes cluster. In our nodes we have completely isolated parts and protected data at runtime, so the question remains: is how can we mesh them together? How can we connect those individual workloads?

A

How can we use um orchestrate them? As you see, on the left side, the control plane there is still no trusted party. So how can we orchestrate those workflows and how can we uh use the cloud services that are already in place?

A

So the next step is about orchestration and one concept. I call the maverick concept map run is an open source project of ours. That's that aims at solving this exact challenge. So the idea is that we lift the individual workload protection to inside entire confidential deployments and the question how marmarand does this is by installing a trusted party into the kubernetes control plane that runs itself inside a secure enclave.

A

The user can connect to that can verify it can provide it with a configuration, and then this trusted party can take care of those specific orchestration tasks that arise with confidential work notes, so it can attest each of them, verify their integrity, use remote attestation and then provide them with trusted configuration parameters because they come from our trusted components and build up secure channels between them and as a plus marion is also able to provide secure channels for specifically supported cloud services, for example, another open source project of ours.

A

The edgeless database uh mabron, can automatically connect your workloads or provide connection security for for connecting to the actuals database, and this is great. It has some downsides because, as you see, it has a lot of uh limitations. You need to specifically install the smart run, control, plane piece. You need to adjust the deployments of your confidential parts to be able to communicate with marburon.

A

uh We only support specific cloud services, but in cases where, in the use case b, where we have new types of applications, this keeps the tcp relatively low and still provides most of the features you would expect in a cloud native environment like scaling, orchestration um database storage, this kind of stuff- and if you want to see an example on this, we took the open service, mesh, bookstore, demo application and we confidentialized them with the components.

A

I've just shown you and you can find this on our blog, but we wanted to go the next step and bring true, lift and shift for the use case, a for bringing all workloads into confidential environments without any changes for a true confidential kubernetes, and we call this constellation and the building block for constellation is confidential, kubernetes nodes. So, instead of protecting individual workloads, we put entire conf entire kubernetes nodes inside confidential vms.

A

So any workload that runs inside these confidential vms automatically is runtime encrypted and protected by svm.

A

And if you would stop there, you would get what's already available on some of the public clouds, which is essentially a managed kubernetes with confidential vms, so the control plane still not trusted still operated by the cloud provider same with cloud most cloud services, but we have memory protection for our individual nodes.

A

So then, what we imagine and what our vision was, is that we don't stop there and we expand this concept to your entire kubernetes cluster. So now also the control plane is trusted. Our cloud services are trusted and you can use uh you have a completely isolated kubernetes cluster from the outside, which you can use as any other kubernetes cluster from the inside and how this works is.

A

You would create your kubernetes resources, your nodes, your control plane, like you, would do in any other kubernetes cluster in the cloud you provide a simple cli for that, so you can just say: okay, create it will spin up a bunch of confidential vms, running a linux image that is prepared for running containerized workloads, that is supporting verifiable boot and has a very minimal image there, and in the next step we would initialize the cluster, which consists of another command called init, and then we have a component in the control plane that connects to all our nodes.

A

Verifies them verifies the integrity using remote attestation and then bootstraps them together in one confidential overlay network, a confidential vpn and from that point on, we have completely a connected cluster of confidential vms that are all verified, and the user can verify this using our coordinator piece obtaining an attestation statement that shows of all those nodes that have just bootstrapped and from that point of view, point of time in time.

A

The user can then connect to this cluster use the cluster using uh the normal board, the normal tools that come with kubernetes and interact with any like any any other kubernetes cluster, because this is a fully functioning cluster and it doesn't stop there if you want, if you have all those features that you would need in a production grade. Kubernetes cluster, like auto scaling, if you deploy workloads that need more computing resources that are already available constellation, will automatically connect to your cloud provider.

A

Api request, new, a new computing node running or confidential vm image would also verify that bootstrap map and add this to the cluster, and you have functional, auto scaling so again, comparing this step where we started with a confidential kubernetes node constellation goes ahead and provides you with full cluster attestation. You also have confidential networking confidential storage. You can use cloud services like key management load balancing and this and it's done in a cloud agnostic manner, so you can run on all of the hyperscaler and use your usual multi-cloud deployment.

A

So we can finally say you can really turn the public cloud into your private cloud. That's it from me for more information on constellation, visit our booth or go to our website at edgeless.systems. Thank you very much.

A