 Hello, everyone. Thanks for coming. My name is Samuel. I work for Rebos. And today, I'm going to talk about confidential computing, the cloud, and a specific project that I'm working on called Confidential Containers. Who knows what confidential computing really is? Yeah? Oh. Halfway through there, yeah. OK, so I'm going to just spend a few minutes trying to describe what confidential computing tries to do and how, I mean, once I explain this, I hope it will make more sense to talk about confidential containers and how we want to use it with Kubernetes. So confidential computing, it's kind of a buzzword. We hear a lot about it, and you probably heard a lot about it this week here. Hopefully, but basically what confidential computing tries to do is to build and bring a new threat model for the cloud, partly and maybe for the use cases. But here today, we're going to talk about the cloud. And if you look at this picture here, this is a simplified software stack, well, actually a stack, an entire stack, of a cloud workload from the hardware up to the guest workload itself, including the BIOS, the firmware, the host kernel, the virtualization layer, everything. And today, today's cloud threat model basically assumes that as a tenant, you're going to trust all of those layers. When you're running your workload in the cloud, public cloud, private cloud, whatever, you have to trust all those layers. You have to trust the virtualization layer. You have to trust the host kernel. You have to trust everything that the cloud provider gives you, basically. What confidential computing tries to do is to move a bunch of those layers out of the trust boundary. And a bunch of those layers is basically the entire host software stack. Anything that's there, from the firmware, from the BIOS, up to the virtualization layer, confidential computing claims that you can remove that from the trust boundary. So basically, you don't have to trust any of those layers anymore, OK? That's a very significant change from the current threat model. It's a drastic change, I would say. And yes, with confidential computing, confidential computing, we're completely removing the cloud provider from the trust boundary. You don't have to trust your cloud provider anymore. You just have to trust yourself, your workload, and the hardware platform. Nothing else. The host firmware, the hypervisor, everything is out. And only the tenant, yourself, when you run your workload on the cloud provider, can see and modify your data, not no one else. And the infrastructure owner, the CSP, no longer has to be trusted. So why is that interesting? And why are there so many efforts going on around confidential computing nowadays? There are many reasons, and there are many use cases that make sense for confidential computing. One of them is basically protecting yourself as a tenant from a malicious infrastructure owner, a malicious cloud provider. Intentionally or not, it doesn't matter. You're just trying to protect yourself from the host, as opposed to the host trying to protect himself from the guest. And a very important point is basically trying to protect yourself from any buggy software that will be running on the host. Even if the cloud provider is not malicious, which, hopefully, most of them are not, you never know if they're running patch or non-patch software layers. You never know what they're running. And you just want to make sure that you don't depend on this for the security of your workload. With confidential computing, you have the hardware guarantee that your data as a tenant is protected. So that brings a lot of new use cases for the public and private cloud. All the financial, medical, governed, basically any regulated market can now run on top of confidential computing hardware, even on public cloud. You don't have to trust your cloud provider. So the data that you generate, that you run, that you push on your workload, is protected. Any sensitive data, you can run on a public cloud with confidential computing. That's the promise, at least. For example, you have a machine learning model that's basically your small company. You're building ML models. That's your business. And you want to protect this. You want to know where your machine learning model is running, what data it's consuming, and where is it coming from, what data it's generating. With confidential computing, you can just run that in any cloud. And you have the hardware guarantee that the infrastructure owner is not going to see what you're doing. That's a pretty powerful promise. And last but not least, with confidential computing, basically you're almost no longer bound to any specific cloud provider. As long as you get the confidential computing implementation from your cloud, you can move workload around. The security attributes no longer depends on what your cloud provider is providing you with. You just need confidential computing. And you can move things between your private cloud and your public cloud, or between public clouds. It doesn't matter as long as you have the confidential computing implementation. So that's nice. And it's very attractive, appealing. How do we do this? There are two things that confidential computing provides. The first one is protection. The CSP, the cloud provider, the infrastructure owner, whatever you want to call it, must no longer see or temper with your data as a tent. So confidential computing implementation must protect your data from the cloud provider, from the infrastructure owner. That's the most basic attribute that confidential computing must provide. But it's not enough. You also want to be able to verify where your data is coming from, how is your data generated? Basically, you want to be able to verify that your software stack, your own software stack, is the one that you expect to be running. If you protect data but you don't know where the data is coming from, if you protect data and you don't know how it's generated, by which software it's generated, it's kind of pointless. Basically, your CSP can change your software stack and it won't see the data, but maybe it has some leaks back into the host and actually get your data back. So you want to make sure that the software stack that you're running as a tenant in your workload is verified, verifiable, verified, and attested. Once you have those two attributes, your data is protected and you verify the software stack that's running inside your workload, you basically have the guarantee that whatever you do in your workload is not accessible from the host. OK, so we need to protect and verify. That's what confidential computing needs to be doing to fulfill those promises. We know how to protect data. We know partly. In transit, we know how to do this. It's basically networking. How do you protect data from one network endpoint to another with this many solutions, TLS, VPNs, whatever combination to do. We know how to protect data at rest. When you store your data, you can encrypt your disk. That's protected. The thing that we don't do and we don't support right now or not yet is how to protect data while it's in use. When you generate data, when you put your data in memory, that's not protected today. So today, you run your cloud workload somewhere in a public or private cloud. You're going to put your data, even in a virtual machine, you're going to put your data in the virtual machine memory. The host can see it, can tamper with it, can modify it, can monitor it, can do anything it wants with this data. So while your data is in use, it's not protected. And what confidential computing provides is memory encryption, but not only memory encryption, it also provides CPU state encryption and integrity, and memory encryption and integrity. So basically, it protects your data. It also protects your workload state from a CPU point of view. Because, yes, if you protect data in memory, that's one thing. But if you let the host actually modify your code flow, for example, if your host can modify your instruction pointer in your CPU state, it can jump on your code and do whatever it wants with your workload, which is not something you want to see. Confidential computing not only provides memory encryption and integrity, but also CPU state encryption and integrity. So it guarantees you that the host won't see the CPU state of your workload while it's running. We have data and CPU state protected. And as I said, it's kind of meaningless if you don't know how this data is generated, where it's coming from, and which software stack has been producing it. So you need to be able, as a guest owner, as a tenant, you need to be able to verify that the software stack that you're going to run in your workload, your library, your container images, anything, is coming from what you expect it's coming from. It's the right bits. It's the right layers. It's the right libraries. It's everything that you expect it to be. So you need to not only protect, but also verify and attest what software stack you're running inside your guest. Last but not least, you also not only need to verify what you're running inside your guest, the software stack, but you also need to be able to verify from the hardware platform that it's trustworthy. So you need to be able to verify that the hardware platform actually is the one that you're expecting, is a hardware platform that is implementing confidential computing as you hope it is. So you need to know that this is a specific implementation of confidential computing that provides you with a certain kind of security attributes, memory encryption, integrity, CPU state memory, encryption, and so on. If you don't have this, again, the host could fake a lot of this. And so you need to verify what you're running inside a guest, and you need to verify the trustworthiness of your hardware platform. Those are the two things that you need to verify. So I talked a lot about a hardware platform, memory encryption, verification, attestation. This is all provided by hardware. There's no magic. There's no super complex implementation. This completely depends on specific hardware implementations. So most silicon vendors, if not all of them, provide or are about to provide confidential computing implementation. One that's already in the market, a few are already in the market. SCV is one of them from AMD. The last iteration of SCV is called S&P. And it's the last confidential computing implementation for AMD. IBM provide two versions of it, PF and SE, secure execution. And Intel, we know Intel is preparing TDX. The TDX specification are available. We know it's coming with some CPU, hopefully soon. But all of those vendors, they provide you with a confidential computing implementation that brings those security attributes that I just talked about. Memory integrity and encryption, CPU state integrity and encryption, and the ability to measure and verify whatever software stack you want to run inside your guest. And also, the ability to tell you which version of the microcode is running, which version of the confidential computing implementation is running, so that you can verify the trustworthiness of the hardware platform itself. Eventually, the only thing you need to trust with those implementation, again, is yourself, your workload, your software stack, and the hardware platform. Everything in here does not include the cloud provider stack or any of the layers that the cloud provider gives you. One very important thing is that all those confidential computing implementation are actually implemented as hardware virtualization extensions. So what does that mean? It basically means that a confidential computing instance is a virtual machine. So an AMD, a CV instance, a TDX instance, a SE instance, is nothing but a virtual machine that has improved and extended security attributes for encrypting memory, encrypting CPU states, having different way of measuring what you're running inside a virtual machine. But they're virtual machines. This is a very important thing. There's no exception to this. There's no silicon vendor that comes and say, I'm going to implement it in another way. It's all virtual machine. It's virtual machine ISA extensions, basically. And that's a very important thing. So this is confidential computing. And what we're trying to do, or what we are doing, with confidential containers, which is the project I'm going to talk about, is basically taking a Kubernetes pod and running each and every pod inside a confidential virtual machine, a confidential computing instance. For each and every pod that you would run in a Kubernetes cluster, we are creating a confidential computing instance, a virtual machine, that has confidential computing attributes. And we run this Kubernetes pod inside this machine, this virtual machine. And I'm going to go now into more details on how we do this and how we achieve that. But it's important to notice a few things. As I said, each Kubernetes pod in this architecture, with this project, gets its own confidential computing instance. You don't create a confidential computing VM per Kubernetes node. You create one per Kubernetes pod. So with confidential containers, we put the trust boundary at the pod level, not at the node level. So inside your Kubernetes node, you can run multiple confidential containers. They're all going to be protected through the same hardware confidential computing security layers. So that gives you a very interesting security attributes per pod. Each pod memory and CPU state is now encrypted and integrity verified. And you can run your pod and basically get a measurement and a verification of the entire software stack that's running inside your pod. Last but not least, the container images that are running inside your pod are encrypted or signed, either way. And they're protected from the host. And I'm going to go into more details about this. But basically, the container images with confidential containers are no longer managed by the host. They stay inside the confidential computing instance. So the host no longer sees the images, which is very important. Last but not least, this is all seamless. And when we design and architected the confidential containers project, the most important requirement that we had is for the user and for the developer to not have to modify its pod definition, its pod lifecycle, and the way you manage your pod. So you take a Kubernetes pod definition. You basically switch the runtime to use your regular runtime to, from your regular runtime to a confidential computing runtime. But you don't have it to change anything else. The same container images, the same definition, same resources, everything is kept intact. You take that definition, you give it to a confidential containers runtime, Kubernetes cluster. And your pod now runs inside its own confidential computing instance. OK, so we basically want to run a Kubernetes pod, or Kubernetes pods, in virtual machines, confidential computing virtual machines. And that sounds very familiar to some of us, at least. It's basically what Cata Containers is trying to do. Well, actually, it's doing. Cata Containers is from very high level. It's just that. You have Cubelet, which is the agent, the Kubernetes agent on the node that manages the workloads on each and every node. Continuity is the container runtime. And with Cata Container, you basically take your pod, put it inside a virtual machine, and your pod is now running seamlessly inside a virtual machine. You don't see a difference from the API. You don't see a difference from the developer perspective. It's all completely unmodified. And you have your pod running inside a virtual machine. So it feels very natural as confidential computing implementation are basically virtual machines to say, if we want to run Kubernetes pod inside confidential computing instances, we should basically extend Cata Containers to support confidential computing. And this is what we did with confidential containers. Confidential containers is basically Cata Containers with a few fairly intrusive extensions to support confidential computing. And we're going to go through those extensions now. Remember, confidential computing is about protecting and verifying. We want to protect data, and we want to be able to verify the entire software stack that's running inside the pod. So this is what we add to Cata Containers to support confidential computing. So in order to protect the data, we had to add to Cata Containers the ability to turn memory and CPU state encryption depending on which confidential computing implementation it's running on top of. So with Cata Containers now, you have a very simple abstraction for turning confidential computing on. So when you configure a Cata Container, you can say, I want to run confidential computing. If it's running on top of a confidential computing, enable CPU. So if you're running on top of an Intel TDX CPU and you turn this knob on, Cata Containers is going to turn memory encryption, CPU state encryption for you just by switching this knob on. And it doesn't matter if it's TDX, or SCV, or SCOPF. The API is the same. The configuration knob is the same. It's completely silicon agnostic. We don't want the host to see the container image. We don't want the host to temper with or modify the container image. But we don't even want the host to see the container image. Kubernetes has an assumption that the container images is completely managed and owned by the host. The host pulls the image, unpack the image, mount the images on the host itself. So it sees the entire workload. And that's not really well aligned, I would say, with confidential computing. So with confidential containers, we changed that life cycle. And now the host no longer sees the container image. And I'll describe in more details how. We only use encrypted or signed container images. Why we do this is because when you pull a container image from a public cloud provider, you're going to use the cloud provider networking control plane. And we don't want the cloud provider to be able to see what you're downloading. So it has to be encrypted if you really care about the provider not seeing the data, or at least sign if you don't care about the data itself. But you want to make sure that the cloud provider cannot temper with the data. And finally, we also, with confidential containers, we're restricting the API that is currently existing between the host and the virtual machine that Cata containers run. So we restrict this API so that the host doesn't have the same leverage into the Cata containers virtual machine. We also need to verify. So with confidential containers, the entire Cata containers stack, and I'll get into more details about this, but it's the entire stack, but not more than this. The container images is not part of the measurement. And I'll explain what I mean by measurement. But with confidential containers, we measure the entire Cata container stack, which means we measure the firmware. If you're booting Cata containers with a guest firmware, the guest kernel, the guest command line, the init-rd, everything that's in init-rd or the root image. And we have all of this measured by the hardware. It's not obviously the host that give you the measurement of your software stack, but the hardware provides you with that measurement. And if that measurement is correct, and we'll see how this could be correct, we get the Cata container get provision with decryption keys to actually decrypt the container images that we can then download, pull, and keep inside the confidential computing instance. So this is Cata containers, and we're going to go through each and every of those steps that I just talked about, protection and verification, and see how we move from this to the actual confidential containers implementation. So first of all, we need to run on top of a piece of hardware that support confidential computing. So that's natural dependency. Once we have this, as I said, you turn on the Cata containers runtime configuration, and you basically run inside a confidential virtual machine. So you get memory encryption, CPU state encryption, and integrity just by turning this on. Now your Cata container pod, your Kubernetes pod running through Cata containers, runs with memory encrypted. As I said, it's a very important feature, mandatory feature for confidential computing, but that's not enough. You want more than this. You want to be able to verify that the virtual machine has been loaded by the host. And you want to make sure that the host actually loaded the right kernel, the right agent, everything that you expect to be running inside the guest. Otherwise, you're basically generating data from something that you don't control. Encrypting data that you don't control is meaningless. So I'm going to talk about measurement and verification and attestation. So I'll just really quickly explain and describe what this is all about in two minutes. When we talk about measurement, it basically means taking a piece of data. It can be code, it can be data, it can be anything. And you basically take, typically, a hash of this big blob or small blob, whatever. It's a blob of data. You take a hash of this. And this is what we call measurement. So when we say we measure the CAD-A guest, basically means that each and every layer in the CAD-A guest, the kernel, the NSRD, the CAD-A agents, everything, not the container images, everything gets measured this way. Take typically a SHA 384, 256, at least. And you get a measurement, get a hash. Then you sign this hash. You take this measurement. You sign it with a key that's available to you as a tenant. You have the public key for this key that gets signed by your platform. And as a tenant, you can take that measurement. You can authenticate it so you know that this measurement is coming from someone that you trust, a hardware platform that you trust. And then you can verify the actual measurement. So once you have the guarantee that the measurement is actually coming from a hardware platform that you trust, you take the measurement and you verify that, yes, this kernel measurement, the hash of my kernel, is exactly the one that I'm expecting to be running inside the guest. And you do the same thing for your kernel command line, your firmware, your NSRD, everything that you want to measure on the CAD-A guest, you go through these steps. So this is attestation, getting a measurement, authenticating it, and verifying it. Once you verify it and you consider that this is the right hash, the right measurement, you say, yes, this is software stack that I trust. It's my software stack, actually. So getting back to the Confidential Container architecture, we're now running inside a confidential virtual machine. So we have memory encryption, CPU encryption, not for free, but actually not for free. But the next thing we want to do is starting measuring our software stack, as I said. So as part of Confidential Containers, we added a new component to CAD-A Containers, which is the attestation agent. And the attestation agent is going to be responsible for measuring the entire stack, the entire CAD-A guest stack. Again, not the container images. So it's measuring the kernel, the firmware, the NSRD. It's measuring itself. It's measuring the CAD-A agent. And by measuring, I mean it's actually asking the hardware platform to send the measurement back. So when you create the Confidential Virtual Machine, you tell the hardware platform, those are the layers that I'm going to put inside the virtual machine. This is the kernel that I'm going to run. This is the Inertity that I'm going to run. This is the command line that I'm going to use. And you just ask the hardware, please measure those. And the measurement is done by the hardware. The host doesn't do the measurement. You just tell the hardware, this is the piece of code that I'm going to run. This is the piece of data that I'm going to run inside my virtual machine. The hardware does the measurement, and the attestation agent in that stack basically talks to the hardware, gets the measurement back. Once it gets the measurement back, it basically has a measurement of the entire CAD-A guest stack. And it can talk to a relying party. This relying party is what we call an attestation service, a key broker, whatever you want to call it. But it's basically something that's owned by you as a tenant. As a guest owner, as a workload owner, you run this piece, or you trust this piece of software that's running off cluster. So we get this measurement from the hardware, and we basically send the measurement, we signed it, and we send the measurement to the attestation service. And the attestation service is now capable of authenticating the measurement. It can tell if this measurement is coming from a TDX machine or a CV machine. It's a legit machine because we actually get the certificate back from the Silicon vendor. Once it's attested and verified this measurement, it can basically establish a secure channel between the relying party and the guest. And most important part, provision the guest with some secret. Now that the relying party actually trusts the guest stack, it can provision it with a secret. And that secret with confidential containers is a decryption key. So the relying party, once it trusts us, is going to provision us with a decryption key. And why do we need a decryption key is because with confidential containers, the container images, as I said, no longer live on the host. They now live inside the guest. So we have the container images inside the guest. Our Kata guest stack has been verified and attested. We get a decryption key back from the relying party. With this decryption key back, we're going to actually decrypt the container images. The container images have been pulled from any registry. Public, private, it doesn't matter. You don't have to trust it, as long as your container images are either encrypted or signed. And you take those keys that get provisioned to you and you decrypt or verify, if they're signed, those container images. So now you're in possession of container images that you trust. You've been able to decrypt them because you have the right secret. Once you are capable of doing that, you can actually start running your container inside your pod. So let's see how this keeps the promises. With that architecture, the CSP, the cloud provider, the infrastructure owner, no longer can see or tamper with a pod's data. The pod is encrypted. The memory is encrypted. The CPU state is encrypted, so that promise is fulfilled. The cloud provider, the infrastructure owner, no longer sees your container images. Your container images go, they are encrypted or signed. They go from a registry to inside your confidential computing instance. And they're not decrypted in the way. They're decrypted once they land there with a key that got provisioned to you after you verified that your software stack is something that you can trust. So you get keys from a relying party and you can decrypt those container images. In all this way, the cloud provider didn't see anything. Or if it sees something, it's something that is signed, that you don't care that it sees it, but you actually want to verify it's the right bits. But it's protected from the host. And as a tenant, you can verify that what you're running is exactly what you expect it to be running. So because you measure the entire CataGuest, you have a hardware guarantee that your kernel, that your initrd, that your kernel command line, that your firmware are exactly the one that you expect. You even have the ability to say, those are the one that I expect, but I know they're buggy. And I'm not going to let these Kubernetes spots start. As a tenant, as a relying party, you can just say, yeah, I know this kernel. It used to be good. It's not good anymore because there's some security issue with it. So I'm not going to provision my keys, and I'm just not going to let you run. And the pod stops there. That has nothing to do. So you can control your workload from your relying party, depending on the policy that you put in place in the attestation service that's running off cluster. And the important thing is that as a tenant, you verify that your pod software stack is the one that you expect before running the pod, before running your workload. So everything is done. Everything is verified before you actually decrypt and start running your container images. With that in place, the CSP is out of the trust boundary. And last but not least, the pod and container images, they're unmodified. You don't need to have special container image content. You don't need to have special pod definitions. Everything is exactly the same as you would run on a regular Kubernetes cluster, except you're using a different runtime, which is Confidence Container Runtime, a variation of Cata containers. So you just need to change your runtime class for those who are familiar with Kubernetes definitions. You switch your runtime class to a Confidence Containers one, and that's about it. Everything else is completely unmodified. So what's the status of the project? We are working towards our first release. We have one gap that we are closing. We actually have a meeting tomorrow where we're going to see this gap being closed through a demo from the folks that are actually closing it, which is basically a secure storage. How do you inject a volume? How do you inject Kubernetes secrets into a Confidence Containers? And this is something that we're closing. So once we have them in place, we are hoping that we can do our first release. It's a growing community, so we have contributors and participants of the community from different communities, different origins. So we have cloud providers like Alibaba, IBM, Microsoft is also starting to work on this. We have Silicon vendors, AMD, Intel, IBM, Reavos as well. We have open source vendors that are contributing to the project. Red Hat is the most important one. So it's a growing community, and I'm sure you want to run it now. I'm sure it convinced everyone here that this is the future. So to get it and to run it, you can use a Kubernetes operator. So we have an operator for Confidence Containers. That's part of the Confidence Containers project. You can take that to deploy your entire Confidence Containers Kubernetes cluster. You can participate. We have a weekly meeting every Thursday, where people discuss the status of the meeting, present new initiatives, new improvements, and so on. And everything is tracked through our GitHub organization. So you can just go there and contribute as well. And I am done for this talk. I'm going to take some questions. I believe we have five minutes for questions if there are some questions. Yes? So the question is, how can you make sure that the measurement from the hardware layer is not lying to you? It's because part of the measurement includes the actual hardware platform measurement itself. So it's signed by the hardware platform, by a certificate that is controlled by the Silicon vendor. So when you get the measurement back, you can verify by talking to a Silicon vendor controlled PKI that it's actually legit, that it's coming from a legit piece of silicon. Another question, yes? Yes, that's correct. So yeah, the question is, do you need to have a special cluster? You don't need a special cluster. You can actually, yes, you're right. You can run multiple pods. And some of them will be running with a confidential container runtime. Some of them will be running with any other runtime in the same node. Yes? More questions? Yep. So the question is, which standard does this use? Unfortunately, there are not a lot of standards around confidential computing. Open Enclave is not a standard. It's a project, more than a standard, I would say. There are, it's not that there's no standards, that there are multiple ones. There are multiple standards, for example, in attestation, multiple implementations. And we're trying to support as many as we can. We're also trying to define a completely abstracted way of sending the measurement to any attestation service in any shape or form. So we're abstracting this because we're talking to a lot of different attestation service backends. So we support many, many backends, but none of them are standardized. We basically, the only thing that we try to comply with is the RATS standard, if you're familiar with this, which is a standard for exchanging attestation messages and verifications. That's pretty much it. Another question, yes? Is there a lot of things that I don't see? OK. I think we're done. Sorry.