 Hi, everybody. Welcome to Cloud Native Supply Chain Security with Tecton and SixthDoor. I'm Kristy Wilson. I'm a software engineer at Google, and I lead the Tecton team. And I'm Priya Wagwa. I'm a software engineer on the Google open-source security team, and I work on a lot of the stuff we're going to talk about today. So this might seem like it's coming out of the blue since real discussions about supply chain security haven't really been happening until the past couple of years. But the reality is that even if it wasn't on your radar, it's been a big problem, and it's definitely something you should be paying attention to. If it hasn't affected you yet, it might just be because you've been lucky. So your supply chain is under threat. And it turns out that these supply chain attacks are far from theoretical. There are more and more of them all the time. A recent report released by Sonatype, and since we're recording this in advance, we don't know if other people have been mentioning this in their talk, so this might be the fifth time you've heard about this. But this recent study shows that there's a 650% year-over-year increase in supply chain attacks. And this isn't just a nuisance. It's costing you a lot of money. And that's why it should be really high priority. Recent studies are showing the cost is in the trillions of dollars. Again, you've probably seen all these zeros already today, but that doesn't make them any less real. But luckily, it is not all bad news, and there are some things you can do to secure your supply chain. So today, we're going to show you how you can use tecton chains to add more security to your tecton-based pipeline. Here's a quick overview of what we're going to show you today. We'll talk a little bit about what tecton is, since in order to be using tecton chains, you need to be using tecton. Then we'll talk about how tecton chains and sigstore fit into this picture. From there, we'll add inspire and talk about what role it plays, and then we'll tie it all back to the salsa levels. Finally, you'll see a demo of the whole thing in action. Let's start by talking about what tecton is, which is a topic very dear to my heart. So tecton is a continuous delivery system that's built on top of Kubernetes. One of its goals is to define a specification for CD workloads that's portable between CD systems. The main pieces of that spec are tasks and pipelines. Tasks are made of steps, which are containers, and pipelines are made up of tasks. For this talk, we're going to be focusing on tasks. So aside from the details of how they're actually executed, for this talk, what's really interesting is their interfaces. Tasks declare the parameters that they need to run, and they also declare the results which they produce after they finish. Together, these parameters and results make up the interface of each task. On this slide, you can see an example of a task that declares two parameters, an image and a docker file, and it declares that after it executes, it will produce two results, an image URL and an image digest. By themselves, tasks don't do anything. In order to actually execute them, you have to create something called a task run, which invokes a task. The task run provides the parameters that satisfy the task runs interface, and in the status of the task run, you can find the values of the results that are produced when a task executes. So in this example, task run, you can see that for the image and docker file parameters that task declared, we're providing the actual values of the image we want to build and where the docker file is located. And once the task run finished, it produced two results, the image URL, which is the same as the one we intended to build, and the image digest of the image that was actually built. So what this means is that if you can observe the execution of a task run, there's some things that you know. You'll know when the task run is completed. You'll know what happened because you can see the task and the steps that were executed. And then via the task results, you can know more information like what artifacts were produced. In the example of the one we were just looking at, you know what image was built. There's a question, though, about how much you can actually trust this information, but we'll get back to that in a bit. Cool. So this is where TectonChains comes in. So at this point, you've done all this cool stuff that Christie just talked about. You've run your task run and you've built an image and pushed it to your registry. And at this point, TectonChains comes in. So you can think of TectonChains as the supply chain security manager for Tecton. And it basically runs alongside Tecton in your Kubernetes cluster, but it acts once your task run has completed. So once your task run has completed, TectonChains will look at your task run and it'll try and see if there's any artifacts in there that it recognizes. So examples of an artifact it might recognize could be an image. It'll take that image and it'll try to sign it. And it'll also generate signed provenance for your entire build. So how does Chains actually sign your code? So this is where something you might have heard of, Six Store, comes into play. So Chains actually leverages each of the tools and services Six Store provides to make signing your software really easy. So under the hood, Six Store uses Cosign to sign both images and adaptations. It uses Recor, which is the public transparency log provided by Six Store, to store records of those signatures and of the provenance adaptation. And it even has experimental support for using FullCO, which is the Six Store certificate authority to generate certificates for software. And this is nice because it allows you to sign your software without having to set up keys or manage public keys. But there's still something missing. So typically, when you're trying to build something in CACD, you tell your build process to run some steps and your build process will run it and it'll tell you what the outcome was. And you just sort of believe it. TectonChains does improve on that a little bit. TectonChains is constantly observing your Tecton pipeline, waiting for your task friends to finish. And as soon as they finish, it attempts to extract images and sign artifacts for you. But unfortunately, there actually is a vulnerability in this system. And the reason for that is that Tecton is built on top of Kubernetes. And to some extent, we are also trusting Kubernetes and we're trusting Tecton. The problem here is that anyone with access to your Kubernetes cluster can go in and edit a task run. So for example, if I'm the admin of my Kubernetes cluster, I could go in and edit every task run I see to say that no image was built or to say that a different image was built. TectonChains will pick up on that task run, believe whatever it's saying, and attempt to sign and generate provenance for that image. So you can see how this is not actually secure because TectonChains is trusting a process that isn't actually safe. So this is where Spiffy and Spire come in. So Spire is another open-source project that you can install on your Kubernetes cluster. And it's basically an identity control plane. It allows you to ensure the identity of the machine you're running on. So when you include Spire as part of your entire supply chain, you can use signatures to attest software, but you can also use signatures to attest the hardware that you are running on. So it provides node and workload at a station, and basically allows you to prove that the pod that you ran on a certain node is actually the pod that was run. So with Spire, we can be sure that a task run is what it claims to be. And this basically eliminates the need to trust the task run in and of itself. So at this point, we have kind of a more secure system on our Kubernetes cluster. So one final element that's missing from the mix that we want to add is salsa. Let's take a look at a video that's going to clear up everything we need to know about salsa. What? No. I had no idea. Priya, I think I just have more questions than answers after watching that, to be honest. Yeah, Christy, I was in that video, but I still think I could use an explanation. All right, so let's talk a little bit about what salsa is. So salsa, oh dear, what does it stand for? Secure supply chain levels of software artifacts. They made me say it 20 times during filming. Supply chain levels for software artifacts. OK, so salsa is a standard that's all about creating levels that allow you to communicate kind of what level your supply chain is at. The end goal is that ultimately what you really want is to have code bases that are auditable and can't be changed by one person that are used to define both the source code that you build and the way that you build it along with verified provenance. Along with hermetic builds and changes that are logged and reviewed by at least two people. So all of this sounds like an awful lot. And that's again why salsa is divided up into levels because you're probably not going to get to the highest hermetic build level right away, but this way you have somewhere to start. So the levels of salsa are the first one is just about having provenance. So basically being able to look at your builds and knowing where everything came from and how it was built, but not necessarily signed. Level two is all about having that provenance but having it signed and then having an element of tamper resistance. So the actual source code and the definitions of the builds themselves are all hosted somewhere. And then from there we can increase the levels by adding non falsifiable provenance and then ultimately in the end level for your builds are hermetic and everything is reviewed and you can completely trust the provenance. But we're not going to go that far today. Let's talk a little bit about salsa level one. So salsa level one is all about fully automating your build process. This means that all of you're not running anything manually you have some kind of script that's defined that shows exactly what's going to execute. And every time you create an artifact, you generate provenance for that artifact that explains how it came into being. The next level up from there is salsa level two, which has all the same requirements as salsa level one, but it adds that version control must be present. So your build steps and your source code must live in version control and the provenance that's being created has to be actually authenticated. So what's great is with tecton chains, as long as you're using version control, which you definitely should be, but taking something we could take that for granted for a moment which I know isn't true for everyone. So if you want to start somewhere definitely start with version control, but assuming we've got version control and play, if you add tecton chains, you can get salsa level two right out of the box. And then with the addition of spire as Priya was discussing, you can actually be on your way towards salsa level three. Priya, maybe you can show us a demo of how you can put all these things together. Let's do it. Okay, I'm going to do a quick demo now to kind of show how we can bring all of these tools tecton chains and spire together. So I've already got a cluster so my current setup is I have a cluster with tecton chains tecton pipelines and spire installed. And the first thing I want to do is create a task that's going to build and push an image for me. And then we're going to use chains to kind of sign that image and generate and find provenance for it as well. So let me show you the task that's going to run. So it's basically a pretty simple task to build and push an image. The, it's got three steps. The first step will just add a Docker file one line from Alpine pretty simple. The second step is going to use canico to build that image and then push it to my registry. And then the last step kind of is required to make this work with tecton chains. But it's going to store the name of the image that was built in a result called image URL. So that happens right here. So we actually have two results in this task. So one is called image digest and one is called image URL and they both refer to the same image. And the reason we need these results is because tecton needs some way to tell tecton chains what image was built. So let change knows what it actually needs to sign. So changes go once this task run has completed changes going to look at it. It's going to see these results and it'll know exactly what image it's supposed to be signing and generating provenance for. So let's apply this pass to a cluster. And then we can take it off with this task run that animal, which just passes in like a couple key things we need for this all to work. So one of them is just this program, which is the name of my image pointed to my own registry. And Docker can take secret which is going to provide the authentication needed to actually push my image to my registry. So we can create our task run and check out the log. And hopefully this will finish pretty fast. Okay, great. So we have now built this image and pushed it to our registry. So this is where tecton chains is going to take over all of the supply chain security that needs to happen once the bill has completed. So at this point, change is going to see that this task run has completed. It's first going to verify the results, verify results that were signed by fire. And if everything is correct, it'll generate a signature and generate some sign provenance. So if you take a look at the task run now, by now change should have probably finished running so we can see some interesting stuff in the actual task run description. So the first thing is this annotation that chains added, which is just that it was actually signed. There was no failure, no error as chains was running. And it actually also adds a second annotation, which points to a log index in the report transparency log. So this log index is going to contain an entry that has details around the signatures that were generated by chains for the specific task run. So we can go in and we can search the log and look at this log index and kind of learn more about this build. There's some stuff down here as well that we should take a look at. So we have the image digest and the image URL that we had specified in the task run itself, but there's actually some new results in there that we didn't add in ourselves and this is actually where fire comes into play. So while the task run was executing when we created, when we stored a result on the task run, we actually also requested a signature from fire to kind of attest that this is that this result is correct and this is actually what happened. So for each result, there's an associated signature proving that the result is correct. We also have an estimate, which is kind of like certificate that fire provided stored as a result. And we're going to use this and change will use a certificate to verify the signatures of the results against the results themselves. If all of this verification checks out, that's when chains knows that the task run wasn't modified that nobody went in and changed it. And so change knows that it's safe to sign the image and generate the science provenance. So at this point, we probably want to check that the image was actually signed as that the attestation itself was signed and we also want to take a look at the attestation itself. So I already set up a signing key as a pair as a Kubernetes secret. So we can take a look at that should be in the text on changing space. And it's called signing secrets. So this holds the private and public key pair that was used for signing. And I actually have the public key just on my computer as well. So we're going to use this to verify all of our signatures. So the first thing we want to do is verify the image itself. And it was called and it's going to change that low. Hopefully this works. Okay, great. Okay, so against the public key, the image was actually signed. And then we can also use cosine to verify the provenance was signed as well. And so cosine verify attestation should work as well. Great. And so it does. And there's some information about the payload itself, which you can base 64 decode and see what the attestation itself was. Now, say I'm a consumer of this image and I need to learn more about how it was built. Or I want to know like what tecton task actually built this image. So I can get the digest of this image. I'm going to grab it from the verification step we just ran. And I can actually search the entire record transparency log and look for entries that match up to this digest. So we see that there is one from the image that we just built. And we can actually take a look at this entry specifically. And you can see that we can find the same attestation that was printed out when we ran the cosine verify attestation command. So with some formatting, we can actually take a look at what this looks like. And we can see an internal attestation for the build that we just ran. So the subject was the image that I just built. Some of the parameters that were passed into the task run are all marked there the name of the task itself and the pod ID that was run. And then in the recipe, we have a step we have a step corresponding to every single step in the task itself. So we have the step where we created our Docker file, the Kanaka step where we built and push the image. And then the final step where we actually wrote the URL to the result and some information about when the build was started and when the build was finished. So this is kind of nice because maybe in a few weeks or a few months after, you know, the task has been deleted from your cluster, you can still go back and see how an image was built. If you if you need to find out more. So this integration between Tecton pipelines and fire is our next step on the road to software three for Tecton and Tecton chain. All right, so the spire support that Priya was just demoing will actually require a few changes to how Tecton pipelines operates. If you want to follow along with those changes. Priya has put together something called a Tecton enhancement proposal or a tip. So actually tip 89 in this case, which describes the problem and we'll be going through all of our different options for how we can add the support into Tecton pipelines. So in closing, Tecton chains can give you at least salsa level to supply chain security for free. As long as you're using Tecton. Great. So what can you do now that you've listened to this talk. Go ahead and try Tecton chains. If you've got Tecton running in your cluster, you can follow along with our getting started tutorial or assigned provenance tutorial. And actually, I think if you do everything in our sign provenance tutorial and start applying it to your actual builds, you should be able to achieve salsa to pretty easily. Yeah. And then you can pin this cool looking metal on your own gallery bow salsa to comply and let's go. It's totally official. It's a totally official metal. Your real thing that Christie didn't draw this morning. All right. Well, thanks very much everybody. It's been great. And yeah, I hope we're I think we're going to be around to answer questions in chat maybe we've already been answering questions I guess we'll see. Great. Thank you so much.