 So, my name is Andrew Blank. I'm a distinguished architect at Red Hat. I've been working in the sigstore community for quite some time, obviously Red Hat being one of the key members of the project. I do a lot with open source, obviously being the, kind of the lead of helm integrations and efforts around sigstore. But I also am a helm maintainer in the helm project. So, definitely if you're interested in more on helm, come swing by on Thursday at 11, I think it is, we're gonna have our helm maintainer talk. So, definitely wanna get as many people who are interested in helm, just swing by. And I do write a lot. I do like to share my knowledge with the community. I have two books that are coming out this year. One, which just dropped about two weeks ago, which is the second edition of Managing Kubernetes Resources with Helm. And then there's a new one coming out in December from Manning around Kubernetes secrets management. So, some cool stuff if you're interested in either one of those topics. So, we know a sigstore, you know, signing the container really is just the tip of the iceberg. There is an entire ecosystem for managing application delivery. There's everything from, oh my good. This is just one small, as you know, this is taken from the cloud native landscape. So, it's one small little component of the cloud native landscape. In there near the top right is helm. Helm is what you would say is the canonical package manager of Kubernetes. It's been a CNCF project for a while. It joined the CNCF in the early days in 2016. And then in 2020 it finally graduated into graduated status. It has an active developer community, 13,000 contributors, a lot of committers. And trust me, as being a maintainer, the flood never stops. It's just like, you know, the guys are just coming and coming and coming. That's good. It means it's a healthy community. The only problem is obviously you want to make sure to keep the community moving when you still have limited number of resources. So, but if you're interested in helm, want to join the project or a great community, so definitely stop on by and do more on that side of things. All right, now the fun. For those of you who don't know helm, how many here have never used helm before? Okay, good. I can go through some of the basics and I won't bore everyone, so perfect. So, helm has a contest of charts. It's a set of templated resources and you combine those with value, which are parameters. You combine them using this helm CLI and you get a release into Kubernetes. And a release can be anything, any Kubernetes resource. It can be just one config map or an entire application of deployments, stateful sets, secrets, you name it. It can all be then created inside of a Kubernetes resource or Kubernetes cluster. A helm chart is composed of the following attributes or basically the following components. At the start, you have your chart.yaml file. This is going to be your metadata. What is the name of the chart? Are there dependencies? Any metadata that goes alongside it? Because we can use certain pieces of metadata to provide rich information for certain user interfaces. Artifact Hub is one of them. It's an easy way to find all the different charts that might be out in the ecosystem. You can provide annotations in your chart.yaml file and that can be populated in a nice user interface for users to take a look at. Aside from that, you have your values.yaml file. These are the parameters, these specific injections, saying, okay, I may want two instances or two replicas of my chart and then you have a template folder which is going to be all your different templated resources. It uses goal-length templates as the underlying language and as well as the sprig module library to add in some special sauce. So you can have a number of reusable components for it in libraries. So, however, most important too, why SIGStore is important, you can sign helm charts. Out of the box, there is a capability to sign helm charts using GPG encryption. There is a concept of a provenance file. It basically is a way that you can prove the identity for your helm chart. It consists of three specific components. The first being just the output of the chart.yaml file, the Shah of the packaged helm chart and the signature of the provenance file itself. And you use the helm CLI to create an apartment to sign the chart. You sign it using helm package-assign. You specify the key you want to use, the key ring for GPG as well as the chart itself. Simple, right? For those of you who do use helm, how many of you are actually signing your charts? Perfect, that's what I thought. Not much. The adoption sucks. So why does SIGStore and helm matter? Because, well, three reasons. One, helm is very popular in the Kubernetes ecosystem. It is the de facto package manager for Kubernetes. Two, we want to support different ways of deploying SIGStore resources. And well, number three, most importantly, we want to sign all the things, so we might as well sign helm charts too. So how do we integrate SIGStore and helm? First of all, we have a plugin, a helm plugin that is. We have the helm SIGStore plugin, which allows us to take an existing helm chart that had been signed out of the box feature of helm and upload that data to Recore. So we can do all the great provenance and understand exactly and assert all the great things that basically falls into our existing ecosystem with SIGStore. Being able to inspect whether the data's there and ensure that it has been managed properly. The three things gets sent to the Recore server from the signed helm chart. First is the public key that was used to sign the chart, the signature of the chart itself, the provenance file, and the hash of the chart. And it obviously provides that one additional level of verification as you're installing the chart to a Kubernetes cluster. And here's a typical workflow of how you would go ahead and make use of this plugin. First, you would just go ahead and create a chart. You would then sign the chart using the out of the box capabilities. You'd upload the chart to Recore using the Helm SIGStore plugin. So Helm SIGStore upload, point at the chart, done. If you wanna go ahead and reverse it, verify it. You just use the Helm SIGStore verify. And you can also search to see if the chart happens to be in Recore. Just say, does this sign chart is in Recore or not? And if you wanna look at the nitty gritty of what actually gets stored in Recore, here's the output of what the Helm Recore entry looks like. How many of you have actually looked at what all the entries in Recore itself? Okay, pretty good. I actually expected less, so good. Also, someone newer is the GA availability of storing Helm charts itself in Recore and in OCI artifacts and OCI registries as OCI artifacts. OCI is artifacts are supported in most container registries. There are a few out there that do not support OCI artifacts. The big one, the big outlier right now is Docker Hub. One of these days, Docker Hub, one of these days, I promise. I've heard good things that it's coming very soon. By signing OCI artifacts using SIGStore's capabilities, it's very familiar with signing container images. You just point it at an existing and away it goes. And co-sign can be used to sign and verify the contents. You can also go instead of signing the package chart itself or the published charts to an OCI artifact, you can just sign the blobs, sign the package charts. You can sign the province file, one or the other, or both. And then you can, once again, you have two files. You can do whatever you want with it. We do the same thing when it comes to co-sign. We sign the co-sign blobs when we are going ahead and publishing the releases. How many of you have actually looked at the workflows in GitHub for how co-sign is released? So that is certainly one way that we're continuing to dog food more of our capabilities because as we do produce the various contents in SIGStore, we are using many of the same capabilities. When we go ahead and we publish the Helm SIGStore plugin, we're going ahead and publishing itself to Rekor. So dog fooding is great because you can find bugs, see where things are working and not working for different use cases. So the last component for how SIGStore and Helm work inside the SIGStore community is we have a set of Helm charts. Three areas that we focus on, number one, we obviously want to enable the Kubernetes deployments of all SIGStore resources. We want to be able to scaffold an entire SIGStore ecosystem within a Kubernetes environment. And as I mentioned earlier, eat our own dog food. I can't tell you how many bugs I found and new enhancements have been created based on this dog fooding. I always love dog fooding because I found so many issues with my own technology because I think, oh, it works in this great use case. But then I try applying it somewhere else, not so much. So we're able to get a greater way of testing. The different components out there, we have all the different key components of SIGStore. We have a number of utilities as Helm charts and we have an overarching scaffolding capability for you to stand up an entire SIGStore ecosystem. So looking ahead, we talked about all the great things. Two areas that I say we want to go forward. We want to be able to evolve the existing content and content creation. And we want to increase the adoption of SIGStore within the Helm community. That's one of the things I am very much interested in, how can we go ahead and get more interest in SIGStore within Helm? Because here's a problem. Helm only supports one way of signing charts, GPG. GPG sucks, it sucks. That's why our project exists. Let's go ahead and let's try to bring new ways of signing Helm charts. SIGStore is not the only one in the play, in play. But it can be one of the various options that can be used in Helm to sign content. So let's go ahead and let's try to make it happen. Let's work as a community, both SIGStore and Helm, to come up with new ways of signing content. How do you get involved? We chat quite a bit on the SIGStore Slack channel and the Kubernetes channel. Please come to our GitHub set of repositories. There's a Helm charts repository in SIGStore, as well as the Helm SIGStore plugin. And then if you are interested in moving the conversation up to Helm to be able to sign additional methods of content, please go ahead and contribute there. Thank you very much. Hope you all enjoyed it.