 Hello, my name is Gergij Broutegom and today I'm going to talk about Secure Delivery, the flux and the open component model. Our time is limited and I would like to also show a quick demo about it so most of the information I'm going to provide will be available through websites and public demos and further readings basically. So let's dive in. The agenda is I'm going to talk about what is OCM, what does it do, how can it help and how do we combine it with flux. So let's talk about OCM first. OCM is called Open Component Model. It's a new standard introduced by SAP and it's basically describes how to deliver software artifacts. So it's an S-bot, it's a software bill of delivery. So you define what you would like to deliver in so-called components and this is all technology agnostic and it's a machine-readable format. So what does this mean in practicality? We define software in blocks of code through YAML. So for example, if you have a software called identipod info, for example, which is a popular testing software, Kubernetes, software that you can deploy in Kubernetes to test it, you would define it. It has a backend, it has a front-end and it has some sort of cache and these are your components basically that you can define in YAML in this new standard, in this new format and once you defined it in this YAML, you can then define further things to do with it, for example, to deliver it somewhere and then verify that the component and its further components are the same as they are. They have resources and sources and further component drafts into it in it and then you would use the OCM CLI which is provided to you to sign this component to verify it. So this is all very complicated, so let's step through it a little bit. So the magic happens because of the tooling that it has. On GitHub, there is a there's an organization called Open Component Model and this organization has all the components that are or all the repositories that are necessary in order to use OCM. You can write your own tooling for the specification, of course, but this has been provided to you. The OCM is the main repository here. This is a library and the CLI together, the library provided to work with the specification and the CLI provides further tools like transferring and signing and verification and building up a component to basically utilize the spec. And so what we did is what does this mean is that basically using this tooling, you can once you define your components, you can create a, for example, you can create a transport archive, something that is called transport archive. And once you sign your components, the signature and verification is all inside the components. It creates an artifact and an OCI blob and you can further then use the tooling to transport this blob anywhere that you want, for example, into a fenced environment or like an ultimate cube boat and an environment that is very strictly monitored. And because of how you use to create this component using the component specification, everything will be offline. Basically, it will be transported to you, including the images, including all the files that are linked with your component and that you provide access to. These accesses that you define, that you would define are many, they basically, they can be a GitHub repository's release artifacts, they can be an OCI repository, they can be a, I don't know, a simple tar file. Anything that you define an access for, it will fetch this component, it will fetch the contents of it, and that's what you will assign and then validate and verify. So there are further options. It's not just, it's not just signing and the verification process. It's also that the, for example, if you have an OCI image that you would like to fetch, once you sign and verify your component, it can be, it needs to be pointing to a local image repository that you have running somewhere, for example, once you transferred from a public place into a local place, you need the component to point to this local environment. So that's localization. When localization happens, everything will be replaced based on some rules that you define in the component file, and these rules will make sure that, for example, images will be replaced. And for example, in a hand chart, instead of pointing to a Bitnami repository or something like that, it will point to a locally downloaded RGZ that contains the hand chart artifacts. That's what localization provides. And then there's configuration, this configuration, it can be further used to configure the end result. So for example, what I will show in the demo is that we have a pod info application. It has certain configuration options, for example, a backend or a background for the web, web interface that it has, or a replica account, for example, how many replicas it runs, one, two, three, whatever. And these are configurable objects. And this is entirely reproducible, so this needs to be something like I can deploy this or I can use this to transfer my component anywhere and it should look the same. So this is a component version. A component version is the specific version of your component. So for example, for pod info, there is a pod info version, which is 0.1.0 and these are the resources that it defines. It has an image artifact that it points to a location. It has a chart and some manifests. The manifests will be used to deploy this application and they are simple Kubernetes manifest objects. And then we have another component reference. So this basically you can reference different components in your component, the skip tour, to build up a hierarchy. So we have a pod info component and it references the backend, it references the frontend, and so on and so forth. So you can build up a dependency chain basically between the components. So the guts of the OCM component is it has sources. These sources point to the actual source that contains your application code. This can be used further for code analysis, for example, or running security checks and so on and so forth. As resources that we saw, these are OCI, RP files, blob, star, hand charts, whatever, and then references which are all the components. So where does flux come in into all of this? Flux is we at Weaverx, working closely together with SAP. We built a system called the MPath system, named pending, which consists of five different controllers, which I'll talk about in a moment. So these controllers use the specification to build up something called the product. This product represents a single application, a single application deployment. We use the OCM specification to build up this application and then further enhance the specification and its capabilities to do delivery. And this we did with flux. Basically what happens is that we take the component resource, we transform it into a Kubernetes object, and then let flux do all the basically the applying and the reconciliation and the version handling and everything like that. It's true flux. So our main repository, for example, that deals with all the manifest that we generate, will go through a flux repository. So we have this concept of a project. A project is the highest, a high-level representation of something that an admin would start to build up. A project could have several components or several products. These products are basically installations and they can, the deployment is done using selecting targets. These are all very new concepts and I am linking to a further reading that can be found here to read about these subscriptions and the product details and all that. So what happens is that we bring in this component, we identify it, we do localization and configuration based on some rules and then using, choosing a target, we deploy the application. So right now, so what is the target? So right now, we only have a Kubernetes target. This means that we will use the end result of all that process, the localization, the configuration and all the replacements and everything and that will result in a manifest bundle. And we will take this manifest bundle and select the target for it. Target selection happens through labels. So for example, you have an environment that is ingress enabled, that has a load balancer deployed and you wish to deploy in this environment, then you would use a label selector called Kubernetes, ingress enable for example. And based on that, we select the target that will have a Kubernetes config file in it and Flux will do the deployment into this remote cluster in a specific namespace. And what it deploys basically is this bundled manifest thingy that we create an OCI repository for. So internally, we are running a OCI registry for the MPAS system and this OCI internal OCI registry is the sharing point between our system and the Flux system. So Flux can read from this OCI registry and we just put stuff into this OCI registry and Flux takes care of the rest. It's beautiful. So enough talk, let's try to walk through the demo really quickly. So I already have this environment running here we have a lot of stuff in here and this is all public. So this demo that I will show here can be found here. This link is in the slides. So MPAS public demo, you can download this and play around with it. It further explains what kind of components there are and what it does and what are the concepts. So let's talk a bit about concepts. We have two organizations. We have the software provider who will build the product and we have a consumer who will consume this product. The product is a pod info application. So we have the MPAS application here and we have the pod info component here. The first thing that we will do is create a release. This release will use OCEM, the CLI, to basically build Tecton we are using in the demo. We use Tecton to do this building process. So here we can follow along how we will use the OCEM library to publish a new release, publish a new component. So basically we build it, we sign it and transfer it. Where do we transfer it? So the transfer is from the provider into the consumers, into the providers OCEM repository. This is a locally running Qtel server. This all runs in the cluster. So once you are finished with the demo you can tear down the whole thing and nothing will remain on your computer. So this is all self-contained. So it will push into the local registry of this component of this software provider organization. The consumer will subscribe or will take from the provider's repository and push it into their own registry. And this is done via a subscription. So subscription subscribes to the software provider and the destination is the consumer's registry. We provide some secrets of course accessing any of this information and for verification purposes we do this. So signing this is very important. The whole chain is verified from the beginning to the end. Once it gets into the MPASS system we sign it with an internal key which is automatically generated and then all of the components in the MPASS system will be able to verify that it's in the system. That this is the same component that we are using and it hasn't been changed on a configuration and localization has been updated but the component itself is still the same. And so the supply chain is basically secured via signing. The OCM library also provides integration with Cosign so we can be assured that our component is the component that we deal with. So once we subscribe to this component I already created a project. The project consists of several folders that describe products and whatnot. So I'm going to merge now into my GitOps repository two projects, products, sorry. One is Podinfo and the other one is VibGitOps which displays information about our cluster. So here the subscription defines that I would like to subscribe, generate a product for this subscription. So once we once we apply this we will get two new pull requests from our system. The pull request contains a bunch of things for example a readme and instruction on how to configure things and the product deployment. This product deployment describes our product, what kind of components it has, what kind of resources it contains and it creates configurations and localizations out of that. What we will also get is a validation check. This checks for validity of the component and it checks for validity of the configuration. If the configuration right now is based on policies but this changed to Q-based configuration in the future. So Q-based configuration can be validated based on a schema. So once I merge this commit the whole deployment and selection and target process starts to spin. It selects a target. It selects a target. We can follow this in the product controller log. All the things are happening. It creates certain things, objects and then it basically deployed the pod info application. It deployed it into this cluster because right now all the target I have in here is a Kubernetes target and it doesn't have a configuration, a Kubernetes configuration in it. So the deployment happened in the same cluster in which the target is residing in. But we have... So once this pod info application has been deployed, the demo is configured with credentials to be able to access it through a... This is the readme for the demo. So you can access basically the pod info through this link. So if I do that, it only works in Chrome at the moment, I should have the pod info application. And I could, I don't know if I still have time, I have 20 seconds left. So if I would go in here into the generated product, which is on the products and would be changing this value, for example, to two or the message or the color, then I could see the change here or a new application would be released. I am out of time though. So this has been secure delivery using Flux and MoCM. Thank you very much.