 Hello everybody, and thank you so much for joining me here at AgroCon for my talk, GitOps, the magic key to cloud native security. My name is Anais Ules, I'm the open-source developer advocate at Acro Security. Now just a quick disclaimer before I get started with the talk, across this conference you're going to hear several really amazing talks on the different ways that people are using cloud native technologies in a very novel way. This talk is really to highlight the security benefits of GitOps that tools such as AgroCD can help you with. If you're already using some of the tools or similar tools that I'm showing in this talk, you might be already familiar with those. Now, let me tell you the story on how I got started with GitOps. I was starting off with my career in the open-source blockchain space, deploying demo applications to distributed ledgers. Then at some point in 2020, I believe, I joined a company called CodeFresh that you might have heard of at this conference as their developer advocate. That was the first time really that I heard about Kubernetes, containerization and GitOps. You have to think about it this way. Lots of people who are entering the tech space right now who are working at companies that use cloud native technologies such as maybe at yours, they are not familiar with different ways of deploying software. They are maybe only then familiar with the GitOps way of deploying their tools, their applications. I really thought GitOps must be the norm. Everybody must be doing it, which is still probably not really the case. That's why we're here at AgroCon to talk more about GitOps and share different ways of using GitOps. Now, at the beginning of last year, 2022, I got started at AcroSecurity as their developer advocate. To be honest, I'm not a security professional. I just want to share different ways on how you can use different tools across the cloud native space to enhance your security if you're also not a security professional. One of those tools is GitOps. In this talk, the main premise is basically that when we apply GitOps as practices, we can increase scan coverage. Scan coverage refers to you being able to scan different components of your application for security issues. The more that you can scan off your application, the higher the scan coverage. So that's a good thing. However, if you're not defining your resources in code, you likely can't scan them. You can't identify security issues with those deployment resources. So usually when we talk about our software supply chain, the different components that go into our application stack that we're using, Git is one of those tools as part of our entire software supply chain. Now, if you're using GitOps, our goal is really to apply GitOps as practices across our entire tooling and really ideally identify all of the libraries, the different packages, the different tools, everything that we're using, everything that we're defining in one way or another to ultimately commit to Git to keep it version controlled to make it observable. Because ultimately, what we cannot see, we cannot scan, and that's something that GitOps really helps us with. It pushes us towards making our tooling, our application more observable and trackable, so we can scan those resources. Now, ultimately, GitOps information are also security information, which is another benefit. When I got started with GitOps at CodeFresh, I was told that it can help us answering these questions. Who can deploy what, or did deploy what? Where was it deployed? How was it deployed? And when was it deployed? Tools such as AgroCD show you everything that happened during those processes. So in case something goes wrong, in case an upgrade to your application goes wrong, you can use AgroCD to answer what actually happened and then be able to be in a position to easier fix those issues. Now, the same questions we can use if we identify a new critical vulnerability, a new critical security issue in our production environment. How did it end up in our production environment? Why wasn't it caught beforehand? Now, we can look at AgroCD, we can look at our deployment history and see what has happened that we didn't catch the security issue before in our build pipeline. So AgroCD has several benefits. It helps us to adopt GitOps best practices. It helps us to define our resources more declaratively, meaning through code we define what should be deployed, how should it be deployed, where should it be deployed. And it also helps us to adopt Kubernetes best practices. So for example, if your application is larger, you might want to use a tool such as home charts to template that application. Now with AgroCD, with AgroCD CIDs, custom resource definitions in Kubernetes, you can easily define how, for example, home charts should be deployed. Now, let's look more at security scanners. What are security scanners? How do they work? I've mentioned security scanning a few times already. Ultimately, security scanners take different information from, for example, vulnerability database on the different vulnerabilities that are found in different libraries. They take information from frameworks and best practices. I'm thinking here, for example, about NSA benchmarks or CAS compliance scans. Now, these benchmarks compliance scans, these definitions tell you based on best practices, how your application should be running, how should it be configured to be optimized in a security focus mindset. It also takes in a list of, for example, misconfigurations. So whenever you're using, for example, a Docker file, Kubernetes YAML manifest, home charts, Terraform, CloudFormation, you're ultimately setting up configurations for your application. Now, it's really easy to introduce misconfigurations. A security scanner will likely have, if they scan for misconfiguration, have a list of common misconfiguration that goes into the security scan. Then you provided the resource that you want to scan. The security scanner compares the information that it has on security issues with what you actually set up, and then it produces a scan report. Now, that's in its high level, really, highest level, how a security scanner would operate. Now, let me tell you a bit about Trivi. Trivi is our open-source security scanner, all among cloud-based security scanner by Accra Security. Now, usually when I give demos, I only showcase open source tools. In my demo later, I'm going to show also codefresh a little bit. So Trivi is basically a security scanner that you can use to scan for vulnerabilities, from its configurations. You can expose secrets in your environments and your configuration files. These are just some of the scanner that it has, and you can scan different scan targets. Scan targets refer to any, for example, configuration resource. It also has some other features, but this is really not a Trivi talk. This is just to highlight that Trivi is one of the open-source scanners out there. Another one, if you want to use one that's within the CNCF is Cubescape. Cubescape is a sandbox project. It does misconfiguration scanning, as well as compliance scanning. So you could also use Cubescape for your security scanning. Now, ideally, you want to identify security issues as early as possible when you get started configuring your different resources. So, for example, when you get started containerizing your application, you want to ultimately then already start scanning it. The container image, the base image that you're using, as well as your Docker file for security issues. The earlier you cache security issues, the easier is it to fix them long-term. Now, if you get started scanning your resources when they're just about to go to your production pipeline, then it's much more difficult to fix them, to identify them, and do something about it. And that's something that GitOps, Agust D also helps us with. If you're using GitOps in your production environment, you likely are not just starting to define your resources in Git right before you deploy them. You likely already built that kind of mentality in the mindset and the processes to define your resources declaratively as early as possible. Now, if you don't identify resources before they hit your production environments, both Cubescape and also Trivi have Kubernetes operators that live inside of your cluster and that scan your resources as they are deployed or changed within your cluster. So for example, the Trivi operator does continue scanning from within your cluster and then produces scan reports based on what it can find. So you can still identify issues as they are running within your different environments. Now, let's look a bit closer at Agust D for additional security scanning. How can it actually help us to introduce more security scanning? Not just the kind of the mindset around GitOps. So as we built our YAML manifest, for example, here's a basic Kubernetes deployment YAML manifest. We can then go ahead and scan that for any security issues. Now, ideally before you build your YAML manifest, your different deployment manifest, you will already want to get started with security scanning across your different resources. So this is really just an example of like once you define the resource that should ultimately be deployed, you scan it for security issues. Here's an example of how you would scan it with Trivi. So you can use the Trivi config command and then scan the deployment YAML manifest for security issues. The screenshot shows a security scan of the deployment YAML manifest that just displays security issues that are of medium severity. You can filter by different severity, you can filter by different information of the security scan. So you run that scan with Trivi, you can fix maybe any misconfiguration issues that you identify and then once you're ready, once you're at the point that you actually want to use Agust D and deploy that YAML manifest, you can create your Agust D resource. What do I define as the Agust D resource? So in this case specifically, I'm specifying the CID, the application CID for Agust D, and the application CID basically states what should be deployed. So in this case, I'm providing the GitHub repository, this should be deployed, the manifest that are within that GitHub repository. How should they be deployed and where should they be deployed? So with Agust D, I cannot only define what should be deployed, the YAML manifest, but also how they should be deployed and updated over time. And then I can also go ahead and actually verify that Agust D manifest that I just showed you. So I'm going to show you an example. I hope you can see it. I'm going to describe what you can see here if you can't see the background. So here I have the application, a similar application YAML manifest for Agust D. It's a custom resource. And first when I was using Trivi and I wanted to scan custom resources with Trivi, I was like, wait, Trivi only has the standard misconfiguration scans for your standard YAML manifest, such as deployments, or services, or other common Kubernetes resources. How can I then ensure that this application CID is actually set up correctly? So you can do that by specifying JSON schema. This JSON schema ultimately states what are the different properties that this YAML manifest should contain. So I can specify here which are the different fields that should be part of this application file. So if somebody sets up, for example, a new application, CRD for Agust D, I can then check that it's set up correctly. So I cannot only ensure that the manifest, the deployment manifest of the actual application is set up correctly and doesn't have introduced any misconfiguration issues in my environments. But I can also then specify how the CRD should look like through JSON schemers. And then I can specify some rego policy here on what are the fields that should be displayed, that should be part of this application YAML manifest. So I'm stating here that the kind of the CRD should be application. Any other kind will not be accepted. That's just the basic theme, for example, of how you could then cross check with rego that your application YAML manifest is actually defined correctly. So I'm passing this in with the trivia commands. I'm saying trivia config again. Then I only want to see high and critical issues, security issues. Now in this case, I define if it's not defined as an application, then that's a high severity issue. So it should be displayed. I'm passing in the policies that I have in the JSON schema with the policy flag into trivia. And then I'm also just specifying the resource that I want to scan. In this case, my application deployment for AguCD. So I'm going to go ahead and run a trivia scan. It detected one configuration file. As you can see, there are no security issues, no misconfiguration issues identified because it's specified as an application. If I run this specified as a different kind, that doesn't really exist, that I shouldn't be using, and I run the scan with trivia again, then it will notify me, hey, there's something wrong in your configuration. It shouldn't be defined this way. It should be of type application. So this is ultimately how I would not only specify what I want to deploy, but also how I want to deploy it. And I can verify that the way I'm deploying it is how I set it up within the policies within my organization. And then I can go ahead and I can deploy the configuration through AguCD in my build pipeline. And also in my build pipeline, I can then make sure that if there's any change to the YAML manifests, if there are any updates, then the resource is scanned again. So in this case, I'm going to just increase it. I have here the dashboard of CodeFresh. I'm just using CodeFresh because it's easy to switch between pipelines and my GitOps dashboard. It's a similar UI, how you would find it with AguCD. So this is basically specifying here my deployment that I just showed you as well as a service. So I have here my website deployment. And I have here, in addition to the website deployment, I have from the trivia operator the different security scans that I could also look at right here through the UI. Now, this is configured also declaratively of, if there are any changes to my main branch or to the main branch, where my deployment YAML manifests lives, then AguCD should make an autism update to the resources to the actual state within my cluster. Now, before that, however, I want to make sure that if there are any issues within the deployment, I can actually have a chance to fix them. And before deploying them to the main branch, and before AguCD does the update. So it's best practice that AguCD does out to things with a specific branch. But actually, if I started, for example, I commit where I make changes to the YAML manifest, I want to ensure that Trivi, for example, in my build pipeline, is able to scan my resources again for security issues. So in this case, my deployment resources for security issues, and I can then change the configuration, should there be any misconfiguration issues. So in this case, there's one medium misconfiguration. So I could look at the build pipeline and see, oh, there's a misconfiguration. I can either choose to ignore it as it might not be impacting my application and give it the approval to merge it into the main branch. And then AguCD will do the update. Or I can say, hey, stop. I want to actually make changes to that commit. So this misconfiguration is not getting deployed through AguCD. So this is ultimately the two areas that AguCD and GitOps will additionally help you to identify misconfiguration issues will help you to identify and enforce best practices of your deployments. Now, just to summarize the different benefits with GitOps, with AguCD, you can increase the scan coverage of your application. So you can ensure that you define all of your visas declaratively right from the start and be able to scan them right from the start as they are getting developed versus as they are getting deployed. It increases your security posture. So you're able to identify when things go wrong, not only from a reliability standpoint, but also from a security standpoint of why they went wrong. And it helps you to increase the control that you have over your resources through better version control. And it provides you with resources, security scanners such as Trivi provide you with trackable and charitable insights on your different security issues. Now, I think I have five minutes for questions. Otherwise, you can find me on Twitter here at Eurlis.nais and here's some of the resources that I've been using. Also, Acra is a coupon. So find us if you want to talk about Trivi and offer open source tools at the Acra booth. Hi. Thanks for the presentation. I was wondering when I saw the schema in JSON for the validation, couldn't you just use like the actual CRD definitions which are written in YAML that you deployed to Kubernetes because they're already finished. I was just asking myself like, where does the JSON schema come from in the end? I wrote that. That's what's coming from. But I don't want to redefine that existing YAML definitions. I guess you could, to be honest, to be completely transparent. I'm just getting started with Rego and JSON schemas. So this was kind of the way that I chose to verify it. So I guess you could. I have to defer that question probably since I haven't tried it. Other questions? Over there. Run. Thanks a lot for the great talk. My question is, how does it work with reporting monitoring several applications? And you know, like all the enterprise features you want to have usually when you have a huge enterprise landscape and you want to implement security for no thousand applications or so, microservices. Dan, you should probably go, if you don't want to configure things by yourself, she should probably go with an enterprise product that provides you all the automations such as aqua security. I just had a conversation right before this talk with somebody saying, hey, we can generate reports through TV. We can output them as like in different file formats and then we can store them somewhere and we can aggregate them and so on. But it's very, it's, it's manual thing to do with the trivia CLI in you from if you have like, let's say hundreds of built patterns, right? How do you do it? Well, in that case, trivia probably doesn't scale to your needs and you should go with an enterprise project. However, there's a lot of things that you can do with trivia and integrating them with other clone native tools. For example, the trivia operator generates, you can set it to write the metrics. It's generating off your different vulnerability reports on different other security reports. And then you can aggregate aggregate them, for example, in your Grafana dashboard or in your different monitoring tools, since it's just, it's, it's Kubernetes native and it's such it's all CRDs and anything that can really work with CRDs will then be able also to work with the trivia operator. I'm giving tomorrow an in booth presentation on exactly that as well. If you take it up. Thank you for the nice presentation. So my question is, is trivia planning to include also some common CRDs, like for example, an Agosti application. Some what some common custom resource definitions like Agosti application is that planned to be included in trivia as well. So let me go back to the other slide. Yeah. Ah, yeah. So all of these, the vulnerability report conflict out of report and so on, all of these are cut based on custom resource definitions that are defined within the operator. So they basically deployed to the cluster and then they define how to scan, for example, a vulnerability scan should be report on, should be done within your of your container images, for example. And what happens then that these scans are attached to that resource that it got scanned. So for example, I have the operator running in this cluster alongside my application. And then it will scan the application, for example, the replica set for different security issues. For example, here I have to misconfiguration scan that's within the cluster of like the deployed users of the cluster. And it specifies here, this is a CRD conflict out of report from the operator. And it specifies everything that's misconfigured within that resource. Does that answer the question? It was a bit different. So you showed us how you set up the JSON schema for an ARC CD application itself. That's also done for a trivia. Yes. Yes. Right now we don't have that like out of the box provided. Yeah, I have to follow up on that. Good question. That would be nice to have. Yes. Thank you. Other questions? Also, Odead, please report to the AV booth. Odead. Other questions? Okay. Well, thank you, Anais. Thank you.