 Hi, everyone, very excited to be here. Nan is, unfortunately, not able to make it today, but she co-built this content with me. We will talk about OCI Artifact, and more specifically, Endchart as well, and how we could deploy them on a GitHub's way and manner. So this QR code is lending to this actual presentation. So you could download the PDF. Quick overview of what's GitHub's. Quickly, we are on a GitHub's day, so you have plenty of content for defining GitHub's. But quickly, we will see in the context of this presentation, we will talk about OCI Artifact, and Endchart, and their advantage. We will talk about config sync, one of the GitHub's tools out there, and OPE Gatekeeper. We will have two demos, actually, one illustrating how you could end-to-end package your Gatekeeper policies and actually deploy them as an OCI Artifact with GitHub's. On the second demo, you will actually package an Endchart for your application, and you will deploy this Endchart on a GitHub's manner as well. Some takeaways and resources at the end. So quickly, when you have clusters and you want to deploy your configuration, so you have your fleets of cluster, and you have different personas building their own manifest, Kubernetes manifest. It could be for security policies, in our case, Gatekeeper policies soon. Could be shared configs, role-binding, cluster role-bindings, other configuration across and widely in your clusters. But it could be more specific for specific apps that apps operator could and want to deploy, actually. The usual way, maybe, could be a push mechanism, Qubectl apply, and other mechanism with a CI CD tool, Jenkins, and others. With GitHub's, the goal here is not to have any more of this push mechanism, but more pool mechanism. So again, you will define the GitHub's engine and tool, maybe Argo CD, Flex CD, in our case, it will be configsing, pooling, actually, the different manifest from different repositories, right? So that's the principle of reconciliation, continuous reconciliation of GitHub's. What's an OCI artifact? Who is using Endchart in their organization? Yeah, couple of, yeah, more than half of the room. Are you familiar with OCI artifact? Yeah, 10 people, ish, cool. So OCI stands for Open Container Initiative, and that's a Linux Foundation project, actually, and the goal is to define, back in the day, with Docker and still with Docker and other partner, is to define what's a specification of an image, a container image, right? Docker container image is one of them, but there is more abstract and generic way to define an OCI artifact or image, and the goal is to have a standard specification to define both the format of the image as well as the runtime to actually run this artifact and image. And Docker container or any container, actually, could be an implementation of OCI artifact, but you could actually package any file. It could be a withme.md file. It could be a Kubernetes manifest. It could be customized overlays. It could be other files, anything, actually, that you are packaging. One of the implementation, as well, is Endchart. An Endchart is an OCI artifact or image. There is multiple of advantages here. It could be generic, again, any files. It's portable, so it's a package that you could port and share across your company. It's efficient and fast, because we will see that OCI artifact could be stored in an OCI registry. So if you are familiar with Docker Pool on a container registry, that's the exact same way to do that. You will be able to do OCI artifact pool, so it's very granular on a security perspective like you have with your container images. As well as very efficient and fast, because I want this specific tar, and archive, and file, and package, right? And like with container, if you think about attestation, verification, cosine, six-tar, and other tools out there to sign and attest your container images, you could actually do that with OCI artifact. So that's very convenient. Confixing is one of the tools. Who is familiar with Confixing? I'm curious. Yeah, one person, perfect. Who is using Argo CD? Wonderful. Flex CD, yeah. So more for Argo CD than Flex CD. But here you could take any GitOps tool and engine. Here we are illustrating with Confixing. It's an open source project from Google, announce LastCubeCon in Europe, Barcelona, or Valencia, and the goal is, I have an engine, I have a component, right? A GitOps controller within one cluster or the fleet of clusters, and I could configure different reconciliation from different repositories, subfolder, branches, et cetera, right? So that's this mechanism, GitSync and GitPool from a Git repository. Confixing, like others, are doing the last mile hydration if you are doing customized overlay, right? You are not, it's not mandatory to hydrate your final manifest. You could directly point to your customization.tml file. What we are exposing and illustrating actually today, those two new adapter and controller where you could sync directly from an end chart, expose in an end registry, and same for OCI registry where you could pull any OCI artifact. It could be also a customized overlay. We are doing the last mile hydration for you. It's not mandatory, but like many talks mentioned that today, complementary tool could be Gatekeeper, for example, or Keyverno. Who is using Gatekeeper? Yeah, Keyverno? Yeah, quite interesting. So here we will illustrate Gatekeeper. So it's not mandatory, it's not part of the product. It's another project based on OPA, a CNCF project. But here you could add more security and policies. So you want to make sure that your manifest respect conformance, compliance and security. And I will illustrate that here. It's an admission controller in Kubernetes and you could actually have rules denying or accepting any request to the Kubernetes API server. I want to deploy this deployment service account or whatever object. Please check that it's compliant with the rules and my own policies. So it's typically a constraint template with a OPA regal with a schema. And then you could implement and extend with constraint. So what we want to do here is doing the demo, two demos, first one is illustrating how to put all of that together, right? So what I want to show you is as security admin, what I want to do is designing and implementing my Gatekeeper policies, right? Manifest file. I want to actually push them in a registry as an OCI artifact, very generic. And the goal with that is to share that more broadly in my organization. People could pull them locally but they could also deploy them in Kubernetes cluster across my organization, for example. So as a security admin, I will be able to do that. So let me show you here. Again, the repo, the demo are available. That's public repository that you could download and see via the slide I shared. But what I have here is in this repo it could be in another repo as a security admin. I will define some constraint and constraint template, actually Gatekeeper policies. Here I have two, but you could have many more. Privilege container. I don't want that people run privilege containers, right? So I'm writing a policies, a constraint for that. And here I could have this template that you could see here where I have my OPA, Rigo policy algorithm, right? And I'm double checking that we shouldn't have anyone running in privilege, right? I'm looking at the pod level or deployment level as well. That's how I do that. If you are familiar with Gatekeeper as a security admin, what I could do as well, which is very convenient, is doing some test case and unit test on my constraint, right? So here we are leveraging the notion of test from Gatekeeper. Again, as a security admin, I should make sure about the edge cases, what's working, denied, or not. So I have a disallowed example and a load example. I should have more coverage here, but that's an example. And why I'm showing you that is because actually I could have in my workflow. So here I'm using GitHub action, right? But pick up any tool you are using out there Azure DevOps, Jenkins, and others. And the goal here is pretty much running some bash script, right? And pretty simple steps. First steps is getting the source. Here I'm using Gator. I don't know if you're familiar with Gator. It's a CLI tool within the Gatekeeper project. So open source project. And you could actually run some comments, CLI command, and evaluating your tests, for example, in this case. And the goal here is to run Gator Verify. So I'm verifying the suite.tml file I designed to do my unit test. And that's part of my CI pipeline, right? And if it's working, unit test are working, I could go actually, oh, sorry about that. Yeah, perfect. So what I want to do is right after, if my tests are successful, what I want to do is in this case, actually log in to GitHub Container Registry, right? So I could log in here to this repository, Registry, actually. So you could have any Container Registry out there, Artifact Registry, GFrog Artifactory, Azure Container Registry, same for AWS, same for Google, and GitHub Container Registry, in this case, or not just to store your container's images, as well they could store and host your OCI images, right? And that's what we will do. So here I'm log in with a tool. I don't know if you're familiar with ORAS. ORAS is a CLI tool based on a Linux Foundation project. And it's again to implement the interaction with Artifact based on the Open Container Initiative. And this tool allow me to log in on a specific OCI registry and look at that what I'm able to do just right after. I'm hydrating my policies. In my case, I'm using Customize, technical detail here. I'm archiving this file, for example, but look at that here. I'm doing ORAS push, like I will do Docker push, right? Here it's for generic OCI artifact. So I'm pushing that in my GitHub Container Registry, right? And if I look at that here, so actually, so there is a graph of the two jobs you just saw in GitHub Action. And part of the demo is actually now anyone who has access, so in my case, it's a public registry. It should be a private registry. I have a link for that. But here anyone could do ORAS pull, like you would do Docker pull. So here you could say, I want to grab the policies of my company, the security policies of Gatekeeper defined by the security admin. So I could do ORAS pull having the manifest and play with that and actually see how I could evaluate them locally on my manifest, for example. And we will illustrate that in a few moments. So next step here is for config sync, but pick up any definition and translation for Flux or Argo CD. We are using an object to define actually for this cluster, I want to pull and deploy these policies. So I'm defining this object, pointing here like you could see, I want to deploy a source type OCI and pointing to this image, right? I just pushed. I'm using authentication none, like I mentioned, it's a public registry. It should be a private registry. And there is a mechanism to secure your access from your cluster in order for config sync, so GitOps engine in our case, to pull this OCI artifact. And if I look after that, if I do here, a Qubectl apply, right? I will be able to see here that actually my configuration, my OCI artifact containing my policies are pulled. And if I look here, I could see that I have all the constraint and constraint template defining my artifact. So now they are deployed. If I look at the constraint, so Qubectl get constraint or constraint template on my cluster, they are now deployed and they could enforce my cluster. I have zero violation in this case, but now I'm enforcing compliance and security. So that's the first part of the demonstration. So here, what we just saw is this part, right? As a security admin, I'm pushing an OCI artifact, wrapping up and packaging my OCI, my gatekeeper policies actually. We had clusters, for example, already provision with config sync and OPA gatekeeper for admission controller. And what we just illustrated, a pool mechanism, a deployment mechanism via GitOps. So that's the first step, first demo, end to end. Now what I want to do is let's do that with an end chart, which is, again, an implementation of OCI artifact. So as an app operator, I want to define the manifest to deploy my app with end chart. So that's something I want to do. So I will have my own repository. I will push my end chart in GitHub container registry, but again, pick up any OCI registry out there. But what we want to illustrate as well is during the CI pipeline, evaluating the policies designed by the security admin. I won't wait to deploy at the end of the day my end chart to see if it's compliant. What I want to do is, again, shifting left the evaluation of gatekeeper policies as soon as I can, right? And not waiting to deploy this end chart in a Kubernetes cluster. So let's see that in action. So here what I want to show you, it's a peer already open. And typically here, what I'm doing, as an app operator, I want to deploy my app. And here I'm looking at some failing failure issue during my peer review, pull request review. And why? Because actually the app operator is changing some information in my end chart. And for example, we could see that we are not using any more an unprivileged container. We are using this one here, which is not a good practice. And look at that, the app operator is removing all the security context, right? So they are removing all of that, so it's less secure. And like we saw earlier, the security admin has policies for not accepting unprivileged sorry container, right? So here it's bad. And before actually waiting for this end chart to be deployed on a Kubernetes cluster, here we are using actually Gator to evaluate this policy within my pipeline. Again, I'm not waiting. And here we could see that, for example, I'm requiring security context and run as non-root, which is best bad practice, and I'm stopping the deployment here. What we are using as well is Trivi. Trivi could scan, so from AquaSec, could scan container images, but they could scan as well Kubernetes manifest. So here there is an illustration of scanning actually your Kubernetes manifest, which is more security check here. We are using a kind cluster where we deploy this end chart and trying to see if there is a smoke test to see if we are fading fast here. And we could see that there is logs and error, right? So here I'm blocking, as soon as I can, shifting left some security guardrail here. So I won't go in detail about the CI pipeline here, but again, it's a lot of check gatekeeper, Trivi scan and others that you could look at and actually reuse because it's bash script at the end of the day. But let's say now the tests are working, right? Like we saw earlier, Auras, Login, Auras pool, we have the same with Elm, right? So if you are familiar with Elm, three steps once the tests are successful. Elm package, so please package my chart with a specific version tag actually. Elm login, again, I'm doing a login on against GitHub container registry and then it's just an Elm push, right? So very, very helpful and interesting here. And same scenario here. If I go here, I could see the flow of my jobs. It's maybe too small, but you have access to that to see more in detail. What I could do again is Elm pool of this artifact. It's a public artifact and image and chart, but again, it should be a private one. I have access to it. And again, I could deploy via this configuration and this deployment, Qubectl apply dash f on this object. Please deploy this Elm image actually, right? So the repo, the name, the version, really name, perfect, thank you. And yeah, that's how I will define now the deployment of this Elm chart, right? So I could see this detail about what was deployed in more case, very simple application with a namespace, a deployment, a service and service account, very basic Elm chart here. And yeah, I have access to my chart. It's all deployed, right? So that's closing the demo part actually here and again, first demo was about security admin, designing, coding their own security, having their own CI pipeline, exposing their gatekeeper policies as OCI artifact and then having configs as a GitOps controller, pooling and deploying these policies across the cluster, if many clusters. And the second part was about apps operator, having the shifting left enforcement, grabbing the policies in the CI pipeline here before actually exposing the Elm chart in OCI registry and then pooling to the Elm chart to actually deploy this Elm chart. So some takeaways here, some of the question we got and Flux is supporting this new OCI format as well as the Git format, our Go CD as a plugin made by Red Hat if I'm not mistaken here. So we could see the evolution of yet another option to do GitOps with your manifest. Yes, Git is still a valuable approach but maybe for some consideration, again, we mentioned at the beginning, fine granular access and security, performance maybe at scale, OCI artifact could be another option for your GitOps scenario. And there is maybe other consideration for again being more performant, portable, et cetera, et cetera. So even if you are using OCI artifact, are we getting rid of Git and do we still have Git as a source of truth? Yes, for sure because we need all this CI part, right? Where all the manifest are in there and the source of truth. What we are doing is having maybe another step where the source of truth for the package you want to deploy is in an OCI registry instead of a Git repository. But we still need Git and what we have illustrated as well here is shifting left again more in the Git and CI pipeline. So that's pretty much it for all the content about this presentation, the demo. There is links here, the setup and the demo. So you could replicate that on your own cluster. I'm using config sync. It's an open source project that you could deploy on any Kubernetes cluster, even kind. And Gatekeeper, open source project as well. I have the link of the project of config sync and the two links at the bottom with the workflow or for the secure manner for pushing your OCI artifact and end charts on a secure GitHub container registry or Google artifact registry as well as pulling them securely from your clusters, right? Links with tutorial associated to that and QR code to download this presentation. Thank you. I hope you enjoy this content and what I would love is maybe taking some question if I have time, yeah? I don't have the mic, yeah. Okay, thank you. So my question is regarding the performance. Can you elaborate how OCI is more performant and? Yeah, good question, yeah. Thank you. So what you could see at scale when you have multiple clusters, multiple repositories, any GitOps controller by design will do a Git sync. So if I could just summarize very roughly, a Git clone, a Git pool on a specific repository branch to be able, for example, to grab a folder, right? So that's how Git protocol is working. So at some point, let's say you have a thousand of repository configuration, all of them will use CPU memory in order to be able to grab a granular or specific folder of files, right? So at scale, you may be, you may see some performance issue on this perspective, right? On your GitOps controller, it works for configs, ARGO CD and FlexID out there. Now with OCI artifact, you are just doing please give me this end chart or this OCI artifact, right? So it's more efficient, more performant because more granular. I hope my answer makes sense and maybe you have seen at scale some of you such maybe performance limitation. Does that answer your question? Yeah, quick. This is kind of tangential, but on topic because you've shown Gatekeeper twice today. I was interested in understanding how you enforce updated security policies on existing deployments. Is that like a, do you just invalidate all deployments? Yeah, good question. Sorry about that. I didn't spend too much time on this Gatekeeper concept. Are you familiar with Gatekeeper at all? Yeah, so the beauty of Gatekeeper is you could evaluate at time T, right? But actually it's a continuous evaluation, right? So every, I don't know, five seconds you could configure that. Please evaluate at this time now within my cluster, for example, right? So that's how you will, if security policies are changing or deployment or object or deploy not just with GitOps but Qubectl, you will be able to have this admission controller checking regularly and auditing your policies. Does that answer your question? So it will reject a good question. So the question is, is it rejecting current workload already deployed? The answer is no, you're right. It's for admission, right? So the new deployment, but what it will do is actually giving you events and violation information. So even if it's not rejecting your current workload it will tell you. And with that you have a reporting tool, trigger notification in order to get fixed as the issue here. So good question, yeah. I just wanted to add on to that previous question. So you can actually run Gatekeeper in auditing mode, in auditing mode to start with because if you actually start off with enforce mode any new application you try to deploy will get blocked and that's gonna cause issues for you. One way for you to look at it or to share it with your entire organizations you can actually build like Grafana dashboards to check out which workloads are actually violating. So that's a good way to start off. Yeah, good call, thank you. I don't have it here, but in my constraint to illustrate that you have an enforcement action attribute. It could be audit or blocking or dry run or et cetera and you could play with that as well. Yeah, good call, yeah. Another Gatekeeper question. So in your Gatekeeper demo you had on the one side a security person saying let's deploy this version of my OCI artifact and on this hand you had a developer in their pipeline saying check my stuff against this version of an OCI artifact. How do you make sure the versions are in sync across multiple clusters and pipelines? It's no idea about that. So good question and it could be a longer answer and the discussion here but you're right. In my case it's a mono repo. I have the policies in the same repo as my app so it was like checking for this specific version. But actually you remember the AurasPool command, right? So you could inject this in different pipeline with let's say latest version of my policies or AurasPool is the latest version or it could be a specific version. So you will need to track that and deal with that at scale and in your thousand pipeline how you deal with the version I could see what you mean with that. So yeah, there is some consideration to have here but something to that could be resolved as well at scale. If I could say. Because a goal also with pipeline Jenkins and others it's definition as code for your pipeline, right? So maybe you could automate some stuff at scale for the version, et cetera, et cetera. Good question. Any other question? All right. Thank you, Matthew. Thank you very much and I hope you enjoy the session. Thank you.