 Cool, thanks for the introduction. Yeah, my name is Fabian. I'm coming from Edge for Systems, and I would like to talk to you about verifiable built environments in the cloud. And yeah, to motivate this and give you a bit of an overview, we want to basically answer the following three questions in the session. So first off, why do we need better built environments in the first place? Then second, we want to explore if confidential computing could be a solution to tackle either one or all of the problems we are currently facing, and how a confidential built environment could actually look like, like an architecture sketch, draft, a first point to basically start thinking about a solution. Okay, first a bit about me. So I have worked five years in automotive enterprise building cloud native key management solutions. And this year I've joined Editor Systems as a senior security engineer. And this is the second talk this year. I will give to share my confidential computing knowledge with Kubernetes community, because I personally wasn't aware of where confidential computing is previously, and it's really starting to take off and get us some real-world benefits. I can also take this off, right? All right, we Edge less building open source tools for the confidential computing space. So on the left-hand side, we have basically our client libraries, Ego as an SDK for building software for enclaves, and we'll go into a bit more detail and further slides. And we also have Marble Run as a service mesh for enclaves, and we have Edge ListDB as a confidential database. And on the right-hand side, we have Constellation as a confidential Kubernetes distribution. And confidential computing in general wants to reduce the trusted compute space, like reduce a trust as little parties as possible in your stack. And building these tools out in the open using GitHub Actions is kind of a bit wacky, right? When we measure the whole stack and make sure that everything is confidential, but at the same time, we're kind of clueless about what really happens in our built environment. So this is only one of the challenges like some companies might face when they want to adapt SAS CI CD solutions. Yeah, the first one is basically a quote from us, so I don't trust the provider. I have zero trust policies as we have for networking, like zero trust is a good thing. You don't want to trust unnecessary parties. This would just increase your vulnerability surface, basically. And then second, a lot of companies I've talked to are worried about intellectual property. So they don't want to give away their code to some unknown untrusted party and take the chance of leaking the code, which is basically all of their business is relying upon that being secret. So third one, we have supply chain attacks and I don't think I need to talk to you about why this is important. But it would be nice if we could know, like can we verify if there was any code injected during the build process and code injected really going down to the lowest level, like was the fear where I manipulated, for example, because this is something we can't measure today. And then lastly, we have data privacy concerns. I come from Germany, so EU regulations are very strong about like not having data or code leave the country. So it might be a bit difficult to trust some, I don't know, CICD solution that is hosted in the US and get your data over there. Okay, so confidential computing. Up until now I just talked about this stuff, like who has actually heard of confidential computing? All right, a few. And who has used like a confidential VM or an enclave before and worked with that? Impressive. Usually there are no hands for that question. All right. So what is confidential computing? First, wide adoption basically started with Intel SGX or they're so-called enclaves, SGX standing for software guard extension. And what this basically provided us was three defining properties. So first one was a process based isolation. The process was isolated from the rest of the system. And at the same time, the process was also runtime memory encrypted. So even if some other process could read the memory of that process break the isolation, it was still encrypted with a key specific to that process and they would just read garbage. And thirdly, remote attestation. And this is really important I think for the whole verifiable build environment. So keep an eye on that one. Remote attestation allows us basically to measure everything that is running inside that enclave, inside that isolated area and then sign it with a trust being inside the CPU, inside the hardware. So the CPU attests to the fact that only the code and data I attended to run in that enclave is actually running there. So this is how this looks in the end. So our app or whatever talks to the hardware and instruct it to create an enclave and then we can load code and data. If we want we can load it encrypted into that enclave and only ever decrypted inside that secure environment with a key only being available inside the enclave. And all of this is enforced by the hardware so I do not need to trust my operating system, the hypervisor, all of those are outside of this boundary. So this is process based without the operating system which is great for a tech service but it's horrible for developer experience, right? You need to touch your code, you need to recompile it so it actually works in that isolated environment where there's nothing but the code and the data you put in there. So the second technology that arose was then confidential VMs which basically widened the surface. It's not just process isolation, you have a whole virtual machine that is isolated from the rest of the things that are running on the same CPU. And the most usable form of confidential VMs is currently from AMD. So it's AMD SEV SMP, that's a mouthful. It's secure encrypted virtualization and secure nested pages so it gives you the same guarantees that we discussed before, like it's an isolated virtual machine with memory encryption at runtime and you can again query the CPU to measure basically over the whole virtual machine down to the firmware level boot loader in it and so on and get an attestation so assigned thing of all the software that is running there. This is realized by the VM directly talking to the CPU. There is a so-called secure processor, an SP that is running inside the CPU and you can basically ask it for those things like create a new confidential machine, measure it and provide me that attestation statement. So how does it look like? Remote party, for example, an administrator or a DevOps engineer or someone wants to verify the state of the virtual machine and they ask the virtual machine for this attestation report. Hit and turn ask the AMD CPU, please verify or provide an attestation about myself and the thing can provide that back to the remote party. It's signed by AMD so you can just download the root CA from AMD and verify that attestation report with it. Inside you will find a list of hashes which basically corresponds to all the different layers of software that are running inside the virtual machine. So the firmware is measured, the boot loader is measured, the OS is measured and everything else you want to include. So we're gonna use these today, like Google and Azure both have confidential computing offerings with slight differences in implementation and AWS has nitro enclaves with a big difference in implementation. I won't get into that. They kind of wrote their own thing, both Google and Azure mostly relying on AMD and also Intel will bring TDX hopefully at some point in time to also provide confidential VM support. Okay, so how can we use that new knowledge, those new computing primitives to tackle the challenges that we talked about earlier? So we have the zero trust policy challenge to tackle this. We really want to establish a root of trust inside the CI CD system. We have supply chain attacks we want to mitigate and we can do this by verifying the build systems integrity down to the lowest levels. And we have those data privacy and IP concerns so we can control the access to sensitive data by having all of it run time encrypted and not being accessible even by the provider of the solution. So how might this look like? So we have five entities or parties involved. We have the enterprise on the one hand side who has the repository with sensitive code and data. And we have a user like an administrator who wants to configure or integrate with that third party SAS provider to use the CI CD offering there. On the SAS provider side, we have two confidential environments. The one is the trusted build service which is basically our root of trust in that environment which can carry out and orchestrate all the builds in the CI CD system. And then we have built environments you're probably familiar with like GitHub actions where you can just request Ubuntu latest as a built environment. Both of these should be confidential primitives either an enclave or a CVM. And then thirdly, we have record and or provenance storage to do to store the metadata and do the verification and so on. Okay, how would we use such a system? So the user initially connects to the trusted build service which was set up by the SAS provider. They can put in the trusted build service binary and run it and the user can basically lock in and for the first time and lock down that system as you would with any server or software like when you set up GitLab for example, you set a root password and look out everyone else. Something similar going on here. But in addition to that, you also want to verify this attestation statement. So it's really like the firmware okay, is the OS okay, is the trusted build service okay and is this all software I expect to run there. We could verify this against the white list but this is kind of static. So what we're doing with with constellation also with our product is we sign and then publish those meta information to record so that customers can dynamically request the newest trusted measurements that we put out there. Which way you prefer is basically based on your risk appetite, right? You can say no, I only want these two bit environments or trust the build services or you say I want to have all that updates. All right, then second, we need to authorize the access like some simple scenario like a webhook as you know from Tecton probably or other build tools could work here where we basically allow the enterprise repository to communicate if an event is happening that should trigger a build. Okay, now for the interesting part. So when a build is triggered, the repository can transfer over the code and the metadata that basically defines our CI CD process and the trusted build service can use this to request the build environment. So if my corresponding GitHub action says Ubuntu latest I can request that I want to have a Ubuntu latest build environment but in addition to trusted build service can also verify those measurements. Am I really certain this is a secure environment before I put in my code and data? And again, same thing. We could verify against the white list or we can ask Rekor other new measurements I should trust. Okay, afterwards we can just forward code and data to the build environment have our artifact produced and stored somewhere. The nice thing about the setup is that the build service which I think is also called build service in salsa is really the man in the middle that can control or at least observe all the information like which code commit was used to build which commands were triggered to build the binary but I can also store these measurement information like which framework was used to host the OS to actually run my build stack in the end. And we can remember all of this information put it in the provenance and then publish it in the end. That's a lot of detailed information like most customers might not be able to reproduce and verify everything. That's quite a huge leap to get to that point but even if we don't verify everything from the beginning we have all the information there and have it in Rekor or some provenance store so we can verify it later or use it later if an incident is happening. Okay, and then we also have the decision whether to use CVMs or enclaves as the build environment, right? So remember, enclave is just a process isolated. You would basically have to rewrite your whole build stack like if you're using GCC or whatever you need to recompile it and make it work in an enclave. That's a huge step to take. You could start with a CVM, just lift and shift. It works out of the box but additionally you can verify like which code is running at the lowest levels. All right, advantages. Yeah, we have the hardware verified root of trust I was writing that horse a lot that helps with the zero trust policies especially for us writing software for that confidential space. We have the hardware verified integrity of the build environment which helps with supply chain attacks and we have an always encrypted build environment that is not accessible for the SAS provider so I can provide my sensitive data and use it to build my artifacts in the end. All right, so quick recap. I think that six-door Salsa and confidential computing could really come together here and bring enhanced privacy and security properties to the CI CD offerings we have today. We're a small startup, 10 engineers so we're busy building the tools we have already but if you're interested in getting in touch maybe building this together as an open source community I'd be more than happy than helping with the confidential parts of the system. Let's explore this idea. I think this has some potential and again it can enable a lot of different scenarios from lift and shift to really high security options for your build environments so I get them out of your data centers and into the SAS offerings we love so much that enable us to write software fast. Again, these are the tools, you find them on GitHub they really help you to get up and started with confidential and this is everything I had prepared so if you have some questions around those ideas there's your chance. All right everyone still sleep you from lunch I think. All right if there are no questions then just find me afterwards, I'll be here all week. You can find me on Twitter, LinkedIn just give me a message and we can meet up anytime. All right, thanks.