 Hello everyone, this is Feynman. I come from Beijing, China. Come today I'm working at Microsoft. I'm also a CNCF ambassador and Microsoft product manager. You can find my Twitter and GitHub profile at Feynman Joe. So in today's webinar, I would like to discuss our daily security concerns and problems, and then I will share how to secure a container supply chain with Notary, Auras, and Radify. Specifically, I will first introduce what is software supply chain security. And next, I will talk about the challenges and the concerns from the industries and our end users. Next, I will walk you through the CNCF open source projects in this area, such as Notary V2, Auras, and Radify. For example, we can leverage Notary V2 to sign and verify artifacts. And we can use Auras to promote artifacts across registries. And if you are running applications on Kubernetes, Radify enables Kubernetes clusters to verify artifacts security prior to deployment. So if you want to automate and build a secure supply chain in CSE pipeline with GitHub actions, we will also provide our practice with these projects. Let's start from the real concerns we hear from our end users. And I guess you might also struggling with these problems in your software delivery process. Not only security engineers, most developers are also concerned about their security in their delivery process. For example, how to sign and verify your container image before you deploy it, how to promote supply chain artifacts from development to production, how to attach spawn file and the signatures to container image to ensure consistency and integrity. We also hear people want to make sure their deployment is secure and view their artifact references in secure supply chain. The most popular problem we hear is that how can we set up a secure supply chain in CSE Deworkflow? So in today's webinar, I hope I can resolve all of those questions and concerns. First of all, I'd like to briefly introduce the software supply chain. Actually, it starts from creation of content such as the building of content like binaries, packages and images. After you created that, you might need to distribute all of those content to different environments, such as you need to distribute the content to your end users and customers. You might also need to distribute and promote across different environments and registries. And finally, the consumption of those content. So you might need to deploy all of those artifacts and apps to the environment. It is interesting that you will find securing software supply chain is similar to secure the traditional manufacturing supply chain. Like the left diagram, it includes several rounds of quality check and testing from producing materials to deliver food to the customers. Ensuring the food is safe enough to the market, okay? When comparing the software supply chain with the traditional manufacturing supply chain, you will find it commonly includes the process of producing software based on multiple dependencies, build and distribute the artifacts and then deploy and publish the apps for customers to access. Looking at the Sensef landscape, you will find there are a lot of open source solutions and projects in the security and compliance section. The Sensef graduated projects like OpenProtestAgent, TUF, incubating projects like Falcon, Notary, Set Manager, and Kiverno. So security ecosystem is very glorious. You don't worry about there's no alternatives in the security projects. When we talk about the secure supply chain, software build of materials, AKA Spawn is also a required concept. US government has executive order to require software vendors to generate and provide Spawn file for customers. We can take a look at the SPDX type of Spawn file at the right diagram. Generally, it includes package file and licensing information and other information so on. Take this diagram as an example. We can introduce Notary to sign your image and generate signature. Then we can use Horace to promote the signed image with signature to a stage environment for deployment. Before you deploy it, you can leverage ratify and OPA can keeper to validate if the image is signed or not. So we will only allow the signed images can be deployed to the Kubernetes clusters and production environment. Okay, let's jump to the first project we wanted to cover in this webinar. Notary V2, which is used to sign and verify artifacts in an easy way. In general, Notary V2 includes three components. Notary CI tool, we can call it notation. It is used to sign and verify artifacts and manage certificates and policies. Okay, look back to the history of the Notary project. You will find it has very wide collaboration on the community. The Notary project was originally started at Docker back in 2015, which is used to provide a general signing infrastructure for containers based on the QA framework. So we can start it from Notation CI. You will find the Notation CI has provided some capabilities like sign artifacts, verify remote artifacts, list all signatures of signed artifacts, and the certificate management like add list or delete certificates. So I will give you a live demo to showcase how to sign and verify artifacts with Notation CI. Okay, let's get started. Before you try out this demo, you need to install Notation and have a container image in your registry. So you will find we are using Notation alpha four, and we have pushed and container image to our registry. So currently we can use Notation list to find the attached signature from this image. Okay, nothing to return. That means there's no signature attached to this image. Okay, next we can create a self-signed test certificate for these signings scenario. So we can use Notation search generous test. We can specify a certificate name. Yeah, it reminds us it is already exists. So it doesn't matter. That means I have already created it before. So we can use Notation key list to list the existing keys. And we can use Notation search list to list the certificates that created by Notation. Next we can sign the container image with cosy envelope. We can type Notation sign with envelope type cosy. So far it has generated a new signature and attached it to the container image. This shot 256, that means this is the digest of this signature. And we can use Notation list to list the attached signature from this image. Next, we can add a public key to this signature. Oh sorry, we can add a public key to the trust door and then we can use Notation search add to specify this public key. Next, we can use Notation search list to find if this key has been added. Next, we can use Notation verify to verify this signature and make sure it has not been tampered by others. Okay, we can type Notation verify with this image name. If it returns the digest, that means congratulations. You have successfully signed and verified this sample image. We just finished the introduction to Notation and bring a demo to you guys. So next, we will briefly introduce Aura's OCI registry as storage. As we mentioned earlier, we can use Aura's to promote supply chain artifacts across different registries. So Aura's is used to working with OCI registries but for secure supply chain scenario. So you can use Aura's to distribute artifacts across clouds and on-premise environments. You can also extend the registries not just for storing container images with Aura's artifacts back support. It also provides OCI registry clients to easily manage OCI artifacts in registries and provides Gola and Python, SDK, and API for developers. Meanwhile, Aura's also has fine-grade capabilities to alter the content of OCI supply chain artifacts. And recently, it has fully supported OCI reference types that means you can use OCI, you can use Aura's with any OCI compliant registries. Country, Aura's is a CNCF sandbox project. It has 76 contributors and has been adopted by Alibaba Cloud, Amazon ECR, GitHub, Microsoft, VMware Tensu, Red Hat, and Singularity Project. Help you to handle these use cases. That means you can use Aura's to pull and push artifacts from or to OCI registries. You can also attach spawn and attestation files to an OCI artifact. You can also use Aura's to migrate images from registry A to registry B. You can also use Aura's to operate repositories and tags in the registries. So as you can see from this diagram, you'll find Oura's has provided a bunch of CI commands like Oura's Attach, which is used to attach files to an existing artifact. Oura's copy allows you to copy artifacts from one target to another's target. Before we get started, let's take a quick look at this workflow powered by Oura's. So let's start from the development process. Developers always build and push their content images to a registry. Let's take doc hub as an example. After that, if you want to attach and spawn to the content image, you can use Oura's copy and Oura's Attach to do this kind of process. So Oura's copy can help you to copy this content image from doc hub to your local registry. And then you can use Oura's Attach to attach a generated spawn file to this content image. Finally, you can use Oura's Discover to view the tree diagram of this artifact graph. So let's get started with this demo. Assuming you have installed Oura's and prepared a content registry, we're using sensef distribution registry as an example. So let's type Oura's copy with source image registry and target registry. You can copy a content image from source to the target place. Next, we need to install a spawn tool which is open source by Microsoft, which is used to generate and create a spawn file. Just make it executable and then we can use it to generate a spdx type of spawn file. Okay, it has generated and exported to a specific folder. Next, we can attach this spawn file to a sample image. Let's type Oura's Attach with this sample image and the spawn file folder, okay? We have attached it to the sample image. Next, we can discover the referrals of this manifest in the remote registry. So we can type Oura's Discover with the image, okay? We can specify the latest tag and show it in a tree view. Okay, kind of we can see that there is a spawn file attached to this image in our local registry. Okay, let's delete this folder that stores the spdx spawn. Next, we can use Oura's pool to pull that artifact from our registry, which is used to improve, which is used to prove if Ouras can pull the artifact with the spawn file to our local folder. Okay, copy it and type it here. So here we need to specify the digest of this spdx spawn. Okay, if we can download the spawn file while Ouras pull, that means we can use Ouras to pull and push any OCA artifacts from the registry. Okay, in our previous two demos, we have generated signatures for our sample image and attached a spawn file to that image. So last but not least, how to verify artifact security prior to deploy it to Kubernetes cluster? I think, ratify is the answer. As we introduced at the beginning of this webinar, we can use ratify to enable Kubernetes clusters to verify artifact prior to our deployment. So as you can see from this part, ratify can work with OPA gatekeeper to enable the policy to check and validate if the contained image meets our verification policy or not. Is this contained image has been signed and validated by ratify? That means it can be deployed to the Kubernetes cluster. If not, it will pass failed and it will not deploy to the Kubernetes. So let's showcase a live demo to demonstrate how can we validate the image and the deployment. So this is the ratify project repo on GitHub and it has recently released beta one. I have already installed ratify beta one in my virtual machine. So if you want to try ratify, you can go to the GitHub repository and download the latest version of ratify. Well, let's go back to my terminal and yeah, I have installed ratify beta one and the next we can use ratify to validate if a signed image can be deployed to the Kubernetes cluster or not. Okay, we can use kukato run signed apps. With this sample image. So for the first time we use a signed image that has been signed by notation. So we can specify a sample image here. Okay, run it. Great, we have created this part with name signed app. So if we want to validate a image that cannot be deployed to the Kubernetes cluster, we can use a image that is unsigned. So we can run unsigned app with this S5 image. So actually we have prepared two types of image in advance. First one is signed and the second one is unsigned. So we can use it directly. Okay, that's it. We got an arrow from the server that is returns from the admission web hook. Actually, this is the OPA. Again, keep a policy we defined before. So it has denied the request to deploy this unsigned image to our Kubernetes cluster. So we can use kukato to get the plot. So as you can find the signed app container image has been deployed to the default namespace. So congratulations, we have finished the last demo. All right, I think we did three demos that demonstrated the workflow in this secure supply chain. So if we want to automate all of those steps in a script, how can we handle that? How can we automate this secure supply chain in a CSED? I think the simplest way is write a workflow script that in a GitHub actions. So actually we have our own practice in GitHub that can be used to create a CSED pipeline with GitHub actions. So you can find these sample actions in this repo, Wabbit Networks. Last but not least, let's quickly recap what we have finished in this webinar. So at first, we introduced the basic concepts of secure supply chain. And second, we walk you through the demos and the project concepts of Notary V2, ORAS and Radify. We have showcased three demos for each project. And last but not least, we presented how you can leverage our practice to build your own CSED pipeline with GitHub actions. So you can go to that repo and find the workflow demo and write it in your own CSED pipeline. That's all from my sharing. Thank you everyone for attending today's webinar. So you can find some resources and the project information from the website. Okay, see you guys. Bye-bye.