Cloud Native Computing Foundation KCD Berlin 2022, 10 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: What can CC do for me? - Fabian Kammel, Edgeless Systems

Description

This talk gives a brief introduction to Confidential Computing (CC) and maps the solution space for CC to add verifiability, isolation, and data protection to the cloud native ecosystem.

Website: https://www.edgeless.systems/

Organized by @Microsoft @kubermatic7173 @SysEleven

Thanks to our sponsors @CapgeminiGlobal, @gardenio, @sysdig, @SUSE, @anynines, @redhat, nginx, serve-u

A

Let's talk a bit about what confidential Computing can do for you, um so what we will be talking today is uh just the basics: what is confidential Computing and then we will dive into the specifics like three different Technologies you can use today in that area.

A

um Maybe a few words about me.

A

So um the last five years I've worked in automotive security, Enterprise security um based on also distributed Cloud native stacks and doing key management, and since this year I joined edgeless systems and we're doing confidential Computing as a startup So I myself am also quite new to that space and I want to share my learnings, basically from the previous six months, what I picked up in the in the space and how it might help you to solve some security issues you might have in your day-to-day business, because I was not aware of what confidential is capable of already.

A

Maybe, let's start with the three letter abbreviations you have in every ecosystem right, so uh confidential Computing has the goal to reduce the TCB The Trusted compute base. This is basically which parties can I remove um from my tech stack, which I don't need to trust. Today, if you have a virtual machine, you need to trust your operating system provider. You need to trust the firmware provider, but you also need to trust the cloud provider to not Snoop into your data. They are not doing this I hope, but they certainly have the capabilities right.

A

They control the hypervisor. They can basically do whatever they want with a classical virtual machines and what confidential Computing also provides us is a remote verification of devices, so we can remotely ask the device hey what software are you running and we get this digitally designed and can be sure that it's really the software we want to have to achieve this. All confidential systems rely on the hardware to provide us with a trusted execution environment, and this is the other big three letter abbreviation oh good.

A

um This basically talks about like some secure part of the system that is carved out of and the other part of the system doesn't have access to. So maybe you know Tes already, because we had them in the past. We have, for example, hsms like Hardware security modules, which are used as a trust anchor for CA management, for example. They are super expensive, like 10 000 of bucks uh for for the hardware and also maintenance SDK.

A

We have smaller things like trusted platform modules, TPMS that are on your main board, hopefully probably, but they can also Only Store a few Keys, like maybe 10, keys and and basic crypto operations. So these are not for general purpose Computing, and that is the goal of confidential light. Have your workload today in a secure environment, we also have stuff like smart cards, but these are proprietary and you need to use the vendors SDK and really build up the knowledge before you can start using them.

A

um So what's the benefit of confidential, it provides us with two New Primitives. The first one are enclaves, and you probably heard about them if you have in the context of Intel sgx, which was launched in 2015, and they provide you with process based isolation. So when you have an application in a process, you can completely isolate that from the rest of the system and confidential virtual machines go one step further. You have your virtual machine with operating system multi-process and the whole thing is then hidden from the cloud provider or general infrastructure provider.

A

No one else, but you the the person who launched that thing has access.

A

Okay, let's go a bit a bit deeper confidential virtual machines. Remove the the cloud infrastructure Provider from this trusted compute base, so you can rent a virtual machine in gcp or Azure. Today, uh click a checkbox and be sure that the cloud provider will not be able to log onto that machine, even if they try to so it's cryptographically.

A

um It's it's encrypted and not possible for them. We will go into more detail on the later slides um and the great thing is: it has the same Hardware resources as virtual machines. Today it runs on your AMD or Intel CPUs. So you have the same performance. You don't need to go into a protected area with limited resources. You can have the same resources as you have, so this enables lift and shift of your current workloads. Any x86 application will also work in that context.

A

Enclaves are a bit different, so these are, as I said, process level, isolation. So there's no operating system Advantage. You don't need to trust your operating system disadvantage. There is no operating system, so you need to use an SDK or somehow else touch your application to make it work inside an enclave.

A

So how is this achieved? Both processes work with with memory isolation, as I said earlier, the memory is encrypted and integrity protected. So you can be sure that anyone tampering with your memory, you you will notice and you can I, don't know, stop your te or take other measures.

A

um We have things like trusted launch, so once your thing has booted up, you can ask it for a proof of that. The software that is running inside your execution environment is the software. You expect. The statement in the end is signed by the hardware. So the hardware is your root of trust, and let's put this in contrast to to classical Computing. So today we can get encryption at rest.

A

um You know this with transparent data encryption in a database, for example encryption in transit. You have TLS the go to basically, but with confidential we also get encryption during processing, so the whole CPU, the states and so on, it's encrypted and cannot be observed or manipulated by the hypervisor, and we have this verifiability. As I said earlier,.

A

Okay, that's not a silver bullet and that's there's. Some limitations and I want to be straight with you. So this is not a mitigation against the side, Channel attacks. We know like Specter and all the follow-up attacks that were published over the last years.

A

um You need the same mitigations as you need for classical VMS, so they won't protect you against side Channel attacks. Physical access attacks are also still possible, like when the cloud provider goes in and measures your DDR bus, like very low level attacks, there's still um yeah possible to attack confidential VMS. That way, but this is super super expensive, so you need to have a really capable attacker and also availability is a limitation. So the hypervisor is still in control. They can shut down your VM anytime.

A

They cannot look into it and I think this is fine, because the cloud provider is like motivated to keep your availability right. They want to keep you as a customer, so I think this aligns pretty well with the motivations and yeah. Why should I care so more and more use cases are required to use confidential, so the irrecept or e-prescription in Germany is required to use confidential, um to secure their workloads or, for example, contact Discovery and signal is already implemented based on sgx, and the cloud providers are also heavily invested in enabling this.

A

So the Azure CTO, for example, spoke earlier this year and said that we will see an expectation that the data is always encrypted in confidential VMS, regardless of the workload like. If you have sensitive data or no, you should enable encryption if it's good security default just use it. There are no no drawbacks.

A

This also protects you from weaknesses in the cloud providers Network, for example. If they have a security breach and attackers get into the network of the cloud provider, they can still not access your confidential VM, because even the cloud provider is not able to so they are also not. They would need to find a flaw in cvms, for example, in the confidential VMS.

A

So, let's talk a bit more concrete about use cases. um Confidential VMS can be used, for example, for remote node attestation. If you think about your kubernetes cluster, we could attest that the nodes that make up our kubernetes cluster are good. So, let's talk a bit more in detail how this works.

A

um We will talk about amd's uh Tech stack into Works, quite similar. Just for the sake of time we chose One tech, um so AMD has secure encrypted virtualization I think for almost five years now, like the first iteration, which began with memory, encryption and they're, adding more and more security features to make these cvms even more secure with with every Hardware Generation.

A

Um They added es encrypted state to also encrypt your CPU register States and, at this point in time, you're really like hiding all the stuff from the cloud provider, and this is what you can use today in Google cloud in azure.

A

um The next iteration will be secure, nested Pages, which also adds memory Integrity protection. This is to be merged into Mainline Linux later this year, I think it's scheduled for 519. So, let's hope for the best we're still waiting for quite some time.

A

Okay, how's, the the trust environment now changed uh with AMD so beforehand. You need to trust all these. These boxes. You see here right. You need to trust your CPUs bios, the device drivers, the hypervisor, so there are really a lot of parties that could attack your system. Even Upstream, like someone could mess with the hypervisor built in the back door and you're susceptible so with cvms. The attack surface is drastically reduced.

A

You only need to trust AMD to provide you good Hardware, and you need to trust your VM I mean you're in full control of what you put into that thing.

A

So how would it look like if you want to spawn such a VM, um the hypervisor, the VM and the hardware need to work together? This is what currently is implemented for SNP and Linux, um so the hypervisor spawns your VM in the end, but the hypervisor is not able to look into this, but in order to talk to your Hardware, um the confidential virtual machine can open up a secure channel to a so-called secure processor, which is on the AMD CPU and can use that for stuff.

A

Like please give me a key or sign some stuff, so basically talk to the root of trust, as I said, to um yeah request certain operations.

A

So now we want to use this to attest our kubernetes node. We launch this and as a remote party as an administrator I, now want to verify that the VM, after it launched actually has the software I was expecting it to have so as a remote party, I can ask my VM to provide me an attestation report, and this attestation report in the end is generated by the CPU.

A

Both parties, the remote party and the VM, can put in metadata into that at a stationary port which can be like Fingerprints of the operating system, Fingerprints of the VMware. So in the end you have a measured boot which is signed by the hardware, and you can verify this with a public key from AMD, and this would basically allow you to build your kubernetes cluster out of confidential VMS and have the guarantee that all the software you are measuring is in a good state.

A

So where can I use these today? As I said, Google cloud and Azure are really great with their confidential offerings. It's as simple as like just clicking a button when spawning your VM to make it uh yeah, measured boot or confidential AWS. They have their own homegrown solution, which is called Nitro enclaves, which is a bit weird because in the end you try to remove the cloud provider from the trust equation.

A

Now they provide me the software for this, so you're still not able to get rid of them, but it's still better than using classical VMS, because you have this whole measured, Boot and encryption to not be susceptible to network based attacks or host based attacks.

A

Mm-Hmm all right now we have a kubernetes cluster comprised of confidential virtual machines. um Next thing would be confidential containers or also called don't trust, your kubernetes admin.

A

So, for example, in the bigger company, you probably have a kubernetes cluster composed of tens of nodes, hundreds of nodes like depending on your company and workload size- um and you probably don't want to trust the kubernetes supplement, because they are external to your application team, maybe even external- to your company depending on it.

A

um So, for that use case we have confidential containers, they provide you the ability to use unmodified containers. So just the container images you have today, they support multiple Tes as a backend, so confidential VMS, for example, and they are able to like fully isolate your container workload from the rest of the kubernetes cluster. Confidential containers are already a cncf sensebox project, so check out the GitHub there's a lot of good information and Samuel gave just a few weeks ago and in Spain a great introduction talk to confidential containers.

A

I won't repeat everything, because this tag is not as straightforward, um but we can have a look uh how it is under the hood, so confidential containers basically use a confidential VM and provide on the other side. Container interface, So, This, Confidential VM in the end, can just be scheduled, like a normal container in your kubernetes, a bit more resource hungry, depending on how you set up the VM, of course, but you get the great benefit of additional security being secure from your kubernetes admin yeah. How does it look like?

A

So you have your normal workloads right. You have persistent workloads or apps or pods or whatever running, and you can simply take a single part, a single container and make it confidential. There are no changes necessary and be sure that your sensitive workload can run in an otherwise untrusted cluster.

A

All right, so last of the three texts would be enclaves, foreign.

A

Sgx enclaves and how you could use this to build a trusted build agent, for example,.

A

So Intel sgx is Intel's software guard extension and it provides you with process based isolation. So your normal app can talk to the CPU and request the CPU to create a new Enclave for you. You can then load encrypted data and encrypted code into that Enclave and both code and data are only decrypted inside that secure environment. So you can have iprotected code. You can have sensitive data. Both are fine to be run inside that thing, they're completely isolated and again runtime memory encryption. Even during computation.

A

No one can have a look at your code or data same as before. We can also do remote attestation, so anyone outside who trusts that our computations are good and not tampered with. Can ask for this remote attestation certificate, as, for example, already used for distributed machine learning like different medical facilities, supplying data to train the same model, and both companies want to be sure that the other one has not exchanged the code in between right to leak, the data or stuff. So you can. Both parties can use the remote attestation to check.

A

Is the software actually what we expect and just Supply the data after the fact.

A

Okay, how could we use this in the kubernetes space, so I think every one of you heard of supply chain attacks over the last few years.

A

They gotten more and more prominent like the most prominent one is probably the the solarwinds hack, but we also have stuff like crypto, minus and npm packages and all the stuff you don't want to deal with actually as a Dev, um but our community was uh was doing a great job of spawning a lot of projects over the last couple of months, so six door, there's I, think someone here from chain guard. You can talk to if you're interested about signing.

A

uh We have salsa from Google for help on the process, side of things and stuff like tof and Toto they're, already securing stuff like the PIP installer in the python environment, and we even had a dedicated track class cubeconna for supply, chain security or a whole con, even not just a track, um but one of the quotes and in the wired article um yeah spoke to me. So keeping tabs on proprietary systems is challenging because security tools need to Foster transparency and validation without exposing competitive, Secrets or IP.

A

So for transparency and validations we have stuff like s-bombs and signing, but for not exposing competitive, Secrets or IP I. Don't think there is really a solution like if you use some sort of SAS offering for CI in theory again they can look at your workload at the data you supply at the code you use to to build your software in the end.

A

Why not use Intel HDX to have a trusted build agent, where you can verify that your build system is actually what you expect it to be you're fully isolated from the cloud provider to build even the most sensitive workloads, and you can export signed information to provide that your build was actually done in a hermetic environment and super secure and can prove that to the end user.

A

All right, then, quick recap, so what you should take away from today is confidential. Computing is already available today, with the security benefits and I presented. You can use confidential, VMS and and enclaves on today's server CPUs you find in Google or azure, and they either provide lift and shift capabilities or high security, depending on your use case and yeah. Let's improve the security of the ecosystem.

A

If you want to start building confidential apps, we etch less, have open source tools for DB for service mesh and they're super easy to use SDK and we're also working on a confidential kubernetes distro. So if you're interested in trying out the attack or using it into your daily business, uh yeah feel free to approach me or ask questions.