Let's see. All right, thanks everyone for joining us today. Whether it's the middle of your day, the morning or the evening, welcome. Thank you to Steve for joining us. We are here to talk about desktop to deployment and K8 security with Chekhov. I'm Libby Schultz and I'll be moderating today's webinar. I'm going to read our code of conduct and then I'll hand it over to Steve Jagair, developer advocate at Palo Alto Networks. A few housekeeping items before we get started. During the webinar, you are not able to speak as an attendee, but you are able to add anything to the chat. We'll collect your questions there and get to as many as we can at the end. So be sure to plug them in right there in that chat we're all using and also say hello. Let us know where you're watching from. This is an official webinar of the CNCF and is such a subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct and please be respectful of all of our fellow participants and presenters. Please also note that the recording and slides will be posted later on today on the CNCF online programs page at community.cncf.io under online programs. They're also available via your registration link that you used to come in today and will be on our online programs YouTube playlist under the CNCF channel. With that, I will hand it over to Steve to kick off today's presentation. Excellent. Thanks Libby. Big thanks to the CNCF. This is exciting to be here. Wow, see people from all over the place. Argentina, India, London. Well, that's near me. Hamburg, Germany. Amazing. What a global audience. Welcome to, while this is called, desktop to developer and I've already done that thing where I've lost my mouse, of course. The alternative name as I'm trying to get it to make it a little bit more exciting because it's something new that I've only just came up with and I've sort of rebranded it to batten down the hatches trying to keep an article, you know, Kubernetes. We like to do that kind of thing with the wheel. My first mate, an open source package is Jackoff. It's something I'll be using throughout to demonstrate what I'm using. Other things that do what it does are available but I would be remiss if I didn't say it's a package that I contribute regularly to so I would be a big fan of it. My name is Steve Jager. I am a developer advocate for Bridge Crew, which is owned by Palo Alto Networks. You can learn more about me there, that URL, and on my Twitter, which I really need to use more often, you know. All right. Let's talk about what we're going to talk about a bit meta. What is infrastructure as code? I'm sure most of you know what that is in some form and some probably in some greater detail. What problems are we trying to solve with it? How many different types are there? Why does it rock? Why does it align very well with GitOps and how they are buddies, particularly in the space of Kubernetes? I'm going to talk a little bit about the code journey because I need that context to start talking about where we apply security throughout the code journey at the different levels, or in this case, I'm going to call them hatches. There might be some patches that maybe you haven't used before you're not aware of, or maybe you'd like to get a little bit of feedback as to where the security people might be putting their little security tidbits and sprinkling little pieces of security on there that might get in the way of making your deployment successful. So that's what we're going to do. And we're going to seek to unlock all of our hatches using checkoff. Okay. We'll talk more about checkoff later, but we'll try and set the scene a little bit more. All right. OSP top 10. It's been around a while. It's kind of like one of the things that apps like people like to bang on about it. Certainly security people love to talk about the OSP top 10, blah, blah, blah. But it's actually kind of getting interesting. Nothing it wasn't before. But there have been some very important changes in the one that was released last year, which kind of recognized this move to cloud native. And I'm very enthusiastic about it. For example, some of the old dog-eared elements of the top 10, like injection and say server-side request forgery, things that were associated with application security, that the apps that people love to talk about, they're kind of getting less important. They're moving down the list. And a lot of them are just kind of gone. Like cross-site scripting is just not there anymore. That was a thing. It's still a very powerful attack vector, but it's just not the ones that should be on our radar. What's super cool now is that this probably shouldn't be super cool, but I think in a geek security way it is very cool. Broken access control, insecure design, security misconfiguration, that's all in the top five. That's awesome. That's not awesome. It's good, but it does realign the way we think about just misconfigurations and infrastructure as code is key to the way we provision our cloud, our Kubernetes, kind of everything. So a lot of this stuff is becoming very important. InfoSec and AppSec are aligning just like Dev and Ops did so long ago. It is important. And kind of what the takeaway here is that coding issues, like what we used to think we were writing things wrong, like sanitizing inputs and making sure we can't get cross-site scripting, and these are being replaced by straight-up misconfigurations or dependency slash supply chain risks. So this is why we're doing talks like this, to try and raise the profile of these things and how we can have security mitigations in place for those risks. Awesome. The problem obviously that these things, bad designs and misconfigurations, the problems that happen is, well, all sorts, right? There are lots of precedents I'm not going to get into. I could spend the whole time talking about examples, but huge outages. We do see a lot of cloud outages, even internally at AWS, for example. Data breaches, lateral movement. So if you've got a weak configuration, security-wise, internally, once they get past that hard outer of the egg, and they're in the soft, yummy innards, being able to move around your organization can be really bad, certainly for things like supply chain compromise. Now, the good news, in addition to the OS top 10, is that misconfigurations are certainly things that are the way our new environments, like cloud, native, and Kubernetes, can be compromised. Those are becoming first-class citizens, and that's great. Just take, for example, this Ingress Engine X issue, let's call it, from last October. It got a CVE number, which is common vulnerability enumeration, normally reserved for things that we associate with more app-sick-style things. That is a good thing. It's not good that there are bugs coming up in Kubernetes and associated components, but it's good that they're getting the attention they deserve. That's pretty solid. There's the problem. What are we trying to solve? It's to make sure all these bad things don't happen. What are we using to provision, and how would we create these problems? What are we using infrastructure as code? Most people are. Very few people are going into the console and going, click, click, click. All right, thanks. Now, I'm going to miss three buckets. Click, click, click. We're not really doing that anymore. We're creating it as code. We're putting it into Git, and that is our single source of truth, and we're doing it in a variety of languages. Now, I've got a few in bold here, and there's a good reason for that.  My repo is done in customize, because I like customize, and it still represents yaml, so that's good. But there's lots of other ones, right? If you have cloud formation, serverless framework, arm, terraform, tons, these are all declarative. Now, there's a lot of really good alternatives to declarative methods, like Ansible is still super popular, believe it or not. Bash, super popular still, of course, probably never going to go away. Lots of procedural things done in Bash, and really new exciting ones like Palumi that are really playing into the hands of languages we're really familiar with, like TypeScript, to create infrastructure as code. So, these are all very valid and very cool. But what do I like about declarative methods, and particularly how Kubernetes leverages them? Well, let's put this in the context of cake. I'm going to bake a cake, and I want to deal with Bash. All right, there's my Bash script for making a cake. I'm sure you've seen Bash before. Bash is going to say, I want to preheat the oven. I'm going to set my layers to zero. I'm going to go into a bit of an F slash loop to make sure the oven's at temperature. I'm going to go through and I'm going to mix the flour with the eggs, sugar style. I'm going to mix it until it's fluffy. What does fluffy mean? I don't know. I don't know how to bake. Nevertheless, we're going to bake it for 30 minutes, and then layers plus plus until we have all our layers. I haven't even started on the icing, fine. Over on cake. Here I'm using, yeah, well, now I could use Terraform, and there's a question in the chat that's asking whether Terraform is in between procedural and declarative. I would say it is not. I say it is very much declarative, and the things that are a part of things that might make it seem non declarative, I think are generally bad practice, but that's a subject for an entire other webinar. What I'm doing as declared is if I am saying I want this, and I am relying on the creation of it and the maintenance of its state. I'm asking for a chocolate cake. I am asking for two layers. I am going to use the fluffy sponge image for my sponge, because I trust that one, and I have scanned it, and it's all good, and Kubernetes is going to make that happen, and that's going to make sure it stays, that I always have two layers. Key difference between procedural and declarative is this phrase called item potency, and that's trade saying that five times fast, but that essentially means if I run my procedural one twice, I get two cakes, I run my declarative twice, declarative, whatever the provider in the case of Terraform or the orchestrator in terms of Kubernetes looks and goes, you already have a cake, you're good. So that's the idea. You can run it more than once, and you still get the same result. That's a key piece of declarative technology. What's also nice is that when I look at what I want, I see the end state, and that's great for security, because it means I can check and go, well, that end state is not secure. Whereas when I'm looking at procedural, I kind of actually need to understand all the logic, because procedural for the most part is called tiering complete. So it means you can do everything with it. You can create loops. You can get loops wrong and create a million layers. And it's very difficult to apply security to understand the end result, and that really requires some advanced, almost static analysis tools to do that. So security becomes already easier. All right, enough cake, right? I'm getting a little bit hungry, and for me, it's approaching the end of the day, so we're going to have to move on. All right, what is GitOps? I'm sure you know what GitOps is, but let's do my take on it, just to double down on that. GitOps is great. It started 2017. This CNCF friendly chap here, Alexis Richardson, who also lives in the same neck of the woods that I do, first started describing GitOps patterns and kind of coined the phrase, yay, hooray, Alexis. Shortly afterwards, this legend of Kubernetes left a comment. Oh, GitOps is the best thing. Whoa. But more importantly, what I put in bold, declarative configuration is the key to dealing with infrastructure as code. I completely agree with that. And kind of just afterwards, maybe it's almost a throwaway comment. It sets the stage for the next generation of tools. Well, check off is one such tool that actually leverages this declarative nature. So in the combination of state as code and the code being the single source of truth, then we have this concept of potential for runtime immutability where we never change runtime. We only ever change code. This is all good. It means we can apply security super early. All right, quick recap. Declarative infrastructure as code indicates the required state. It is answering the question of what do I want as opposed to how do I want it? And it was relying on a provider or to create that for me. The languages we will be using, YAML, HALM, and Customize, everybody loves YAML. These are the Kubernetes open source infrastructures code languages that are famous for, well, most, I'd say YAML is probably mostly famous for Kubernetes. Of course, things like GitHub Actions as well. Declaring resource objects and relationships. And we can leverage that for security. Because GitOps establishes Git as the single source of truth, Git equals runtime. So why scan runtime when I can scan Git? Because I know what the state is going to be. Fabulous. Now, something I'm not going to talk about, there is a notion of drift, which is when if you're doing all of this, and then somehow your runtime doesn't match your code, that's bad. But we'll talk about that maybe in another webinar. All right, let's take a little journey alongside all of our code. Our code starts on our desktop as a small child. And it moves throughout the pipeline through all these various stages, which are kind of the hatches. These are the moments that, well, security enthusiasts like me, like to think, all right, well, can I throw some security in there? How hard is that going to be? And then there's a reality of who is responsible for each part of this pipeline? How difficult is it to put those in place? And you can kind of see I've got some markers on there. Certainly way over on the left, on the desktop, if I find a problem on my desktop, whether it's just a programmatic problem, or whether it's like just a spelling mistake, or missing whatever, or bracket, I mean, I find it, I fix it there. There are lots of NIDE linters and checkers that help me do all that. That's the fastest and easiest way to fix problems right there. And then what's cool is that that labor is divided amongst thousands of developers. And I'm probably maybe only looking at, say I'm only looking at one large deployment that has 10 different resources, a service and ingress, pods, all that kind of stuff, right? I got it all in my head. It's all good. Well, it progresses through, I might do some things in the command line. So I included it there because there is an option for security there. Maybe I set some things up. Maybe I do my git by the command line. And I might be I use something pre-commit. If you're not familiar with pre-commit, there's a pre-commit hook that you can use a framework and we'll see it in a moment. And then it goes into CI. So this is why we're kind of all safe and blue. In CI, well, now we have this option to add all sorts of wonderful things, right? And it's really easy to do things in CI. And then it goes to CD and we're something that is managing our deployment like flux or Argo and boom, it's off in runtime. And that's why I've got runtime in red. Like once we're in runtime, well, now that's the scary part that the poor 10 security people, and by the way, that is a roughly accurate estimate. If you've got a thousand developers, you probably have 10 security people. And they're monitoring and they're just kind of sweating and hoping for the best that they don't ever detect an anomaly and that their complicated security tools that are looking for those anomalies are complicated enough for the complication of the anomalies. It's nuts. It's not, it's an expensive part of security is doing things at the end, whether it be pen testing, whether it be looking for things with EBPF, it's hard. The reality of deploying is that monitoring is always going to happen. You have to do it. But your value for money isn't CI really, because whether it be GitHub actions or Circle CI or whatever it is you want to do, there's always going to be some way to drop some easy security in there. And check off is no different. There is an easy way to do that. But from a developer perspective, what I'm trying to demonstrate here is that there are earlier options. Something breaking in CI is not necessarily cool. Like if it gets flagged, happens all the time. But it would be great if it could flow all the way through there. If I used some of the earlier gates myself to make that happen, that would be better. And if the state of DevOps report is to be believed, and of course it is because it's amazing research, then most organizations are kind of like in the mid-level of their DevOps, kind of transformation or culture, right? Which means there's probably about a day between a check-in and something may be breaking in CI.  If you're enterprise, it may be weak. But there is a kind of a published average there. And that's not great, right? Because I always like to think when I've checked something in, it's like, I'm done. I can go work on something else now. I can switch my brain into a new gear and I can go. So how can I make sure that even though I know that there will be security measures in CI, they're not going to bother me? All right. Well, let's take a look. Let's take a look at how we can do that in an easy way. I'll start by introducing check-off because if you've never heard of check-off, well, then I have to tell you what it's done. Of course, free and open source misconfiguration scanner for IAC for infrastructure as code intended to be used in CI pipelines. That's kind of how it was originally built. How many, there's lots of different rules and checks and policies, but those span many, many languages. It covers all major infrastructure as code languages. It's not like I have thousands for Kubernetes. You bring it and explode. Do you even consider that there would be that many? At least I hope there isn't. But they're mainly best practices. Some of them are certainly security related. Some of them are just, this is a bad way to do things. And some of them are, I've got graph-based analysis checks. That just means we're checking relationships as well. So if this is connected to this, then let's just make sure that all makes sense. You can get it for free at checkoff.io. I have a check-off dot right here. If you just want to kind of bring that up. Hey, there we go. That's what check-off. You can download it. You can look at that. It's free. Go grab it. All right. Customize.io. Okay. So you may use the ML. You may use Helm. You may go, okay, I've heard of Customize, but I don't want to use it. You'll notice there's a little goat on top of the M here. That's because we're working on a repo. You could see it's huge on the bottom of the screen. Rich Crew.io. Customize.goat. Where we're trying to create a development deployment. It's an Internet deployment. It's got its own container image that is just, frankly, default. Let's call it default. It's not secure. Defaults are rarely secure. And then there's a path for prod that actually everything's fixed. And it should go past most, I would hope, security context or security checks. So we've got both in there. We're going to start expanding it to add more kind of vulnerable elements in there. And even checking Customize that manifests as well. Customize. I'll explain a little bit more when we get to the hands-on. Okay. Getting back to here, what we're going to do is, you can see I've got the little hatches, right? If runtime equals freedom, then we need to get through all of these in order to make that happen. And I'm going to show what the security measures kind of look like at each one. I guess it's probably easier to do it. And so ideally we're going to go backwards. I'm going to start hatch five, then go to four and the three, the two and the one. And then hopefully you get a feel for when security people like to lecture or about shift left, or if you go to a conference and you're like, what is shift left? Can you see this in KUKON? This is what we're talking about. We assume developers know what that means. And frankly, most of the time they don't. This doesn't mean throw all the security at you. What it actually means is, well, even doing some security at deployment is better than runtime. I still call that shift left. Distribute left. Many hands make the light work. That's what we're going for. All right. Let's do some hands-on. Let's do some playing. This is way more fun. Let me adjust my microphone and try not to make it so noisy. Hatch five. This is, I think this is the one from lost, that series lost. All right. This is a Kubernetes admission controller location deployment. The pros of an admission controller. We usually, now this is, this is personal opinion. Let me just make that absolutely clear. It's applying the no-brainer security controls pre-flight. If you've gone all the way to the point where Kubernetes is checking what you're doing, I hope you've done some stuff beforehand. Right? Because certainly, the admission controller that we've got for check-off, it doesn't check everything. It checks the stuff that's super bad. Think of it like a bouncer at a club. The bouncer doesn't want to know your back history. It doesn't want to know your hopes and dreams. It doesn't know if you have a criminal record. It doesn't know anything about you. What it does do is look at your shoes and say, I don't like your shoes. And that baseball bat you're carrying that looks threatening. This is the admission controller. Now the good news about the pre-flight is that it's an admission controller. So it is a Kubernetes object that can be controlled by Git. Huzzah. Check-offs under the hood. Now you're probably thinking, I'm just plugging a check-off. What I really mean by that? Well, yeah, that is good. But what I really mean by that is consistency and security is good. So if I'm using something in my admission controller and I can use that earlier, the same checks with the same tools, that's good. Because that means if I pass my own security standards using this tool, then there's going to be some weird thing in the admission controller that's going to catch me out. So knowing, it sets reasonable expectations. So that's a good thing, consistency. Bridge Crew Platform does measure, does keep track of checks even if they're on the command line. So you have a single point of reference. I'm only going to say this here because I realize it sounds like an ad. So forget that. Optional. Ares are not always conveniently visible to developers. Getting blocked by an admission controller is, well, it's kind of annoying, actually. Fixes may require re-indocumentation. I had to put that in there because it's kind of obvious, right? So let's see in action. What does that, what happens? All right. So let's swipe over here. Let's make sure my Kubernetes cluster is still alive by just seeing what's in it. Here we go. All right. So I've got a, I am using, what am I using? I'm using Rancher Desktop. So I have a Rancher Kubernetes cluster here. I'm in my Kubernetes Goat directory. And you can see that I've deployed a validation webhook here. This is the one that's got checkup hiding out in it. And I'm going to use, I'm going to just do the basics. First though, actually, my repo looks like, oh, okay. Now you can ignore all this stuff at the top because this is just me setting up the image. But down here, this is the, these are the manifests. I can probably get away with doing that. Okay, great. Here's the base. Now the way Customize works, if you don't already know, it's kind of like a class structure, which is why I really like it. My base deployment is here. It's got my deployment, my service, my storage. I could have put these on one file, but I like the fact that they're separated out. Why? Because what Customize does is, it creates this overlay or almost like an override. So for development, I'm not overriding anything. In fact, all this Customize YAML says is, my base is up here in base so that there's a kind of a drawing a connection between the two. Same as Customize says my overlays are here. So there's just a simple file that says, this is how we do things. Customize can do lots of other clever things like generate config maps and all sorts of wonderful stuff. Go check it out, but we're not going to get into that here. If you look at test, okay, I'm overriding the deployment a little bit. And then here, I'll opt to make sure that it's secure. If you get an idea for it, we can say look at cat, Customize, let's look at base, and let's look at the deployment, right? Here's a pretty simple deployment. Now, if you think, that looks, other than the fact that there's an image here that we're using that's special, this is kind of a cut and paste from kubernetes.io where there's an article that everybody starts with, the deployment x. This is straight out of it. All I've done is change the image. And then if you want to know what a template looks like, they kind of look a bit freaky, actually, because they don't always have, let's go to overlays, they don't always have the full compliment of things because they don't need to with an override. So look at this weird thing. This is an overlay. And actually all I'm doing is changing the replicas, adding some annotations, and adding some anti-affinity. But on its own, this is useless. So hopefully you get a feel for that. So imagine base plus overlay equals deployment or equals result, manifest. That's what we're going to do. So we clear this and let's have a go then. Let's apply the bad one, right? dash k. Now, if you're not familiar, Customize is built into kubectl. Instead of a dash f, use dash k. It's right there. You don't have to have a plugin or anything super special like that. Just do it. And overlays, and I'm going to go dev. That's it. I want everything in there to go. That seems to make sense to me. There's a service in there. Yep, that works. Nothing wrong with the service. So you remember, there was no, I think there was a service file in there. So it grabbed it. Oh, no, dev doesn't have anything. So it's grabbed the service out of base. Now, this is taking a little longer. Why? Because the deployment is not great. And when the Admission Controller doesn't fails it like that, we're going to get some feedback. So this is pretty standard Kubernetes stuff here. Error from the server when creating this Admission Webhook denied the request. Okay, normal. Any Admission Controller will do that. The custom information is that there was two issues that were in violation of the Admission Policy. And there is this one here. Containers were wearing the wrong sneakers. And here we go. You should not try to enter this club without a baseball bat. Now, there is 17 total issues. So this is what I meant by the no-brainers. We have the Admission Controller by default, just looking for really bad stuff. But we do give you a link on how to go look at all the rest of it. I'm not going to go there. I'm just making you aware you can do that. Okay, so that is what it looks like. Now, where would this text be? It's going to be a log somewhere, right? Like an ROCD or somewhere, but it's not going to be in front of you. So it's good for security. It's kind of battery developers. It's a pain in the backside. All right. The cons. Error is not going to be really visible. We talked about that. All right. Ash number four. There's the safe. That's what we're after. What's hatch four? This is the ROI location. This is where security is definitely going to be. If it's not there, it's going to be there soon. You get four more granular security controls. You're not going to be looking for the low hanging fruit, the bad stuff, just root. You can do everything there. Again, control by Git. Plugins are available. So super easy. Instant ROI for both security and ops. Awesome. Cons. Once again, the errors are not conveniently there for you. So let's take a look at what that looks like. Now I have to go the other way. Back over here. All right. Here's customized code. I hope that's big enough. I think it will be. I can probably bump it up a little bit so we can do that. All right. Now we saw the tree of what's here. This is exactly the repo. Customized code. I'm going to pop in and look at the workflows. I've got two workflows set up. I've got one for prod. And actually, I think I've specifically set up prod only to ever go when I make changes to prod. And I need to add. I only just made this. So I'll add base to that. And then for dev, I'm checking anytime anything changes, this is going to fire. This morning, I actually made a change to the name of preflight. And of course, my check for dev CD ran to reduce security. And it failed. Now you can see there's annotations here. We're putting a Sarah format. So we can see some of the bad things that are here, which is all right. And if I want to look at apply security context, I can click in here and it's going to leap into my logs and jump down and show me exactly where that one was. Okay. It's getting a little better. I can see that I should not run with allow privilege escalation, or I can look up and see that readiness probe should be configured. Like this is, these are all good, legitimate things that I probably should learn, learn how to do. And in fact, I can even click here on these guides and I can go straight to the information that tells me how to fix it with little cut and paste answers that I can add to my code. Cool. We're getting better because now I'm getting some help. I'm getting, I'm getting fixes. This is all very good. But I mean here, this is where I have to go find all. Okay. All right. It's good. That's not great. All right. Let's jump back over here. So probably worth knowing this is, if you're familiar with CI, you know, this is how it's going to happen. Hatch three. The ones that we can do, I think, that are make life a lot easier. Pre-commit. If you're not familiar with pre-commit, let me just talk about the pros of pre-commit. Again, you get the same advantage as you had before. Errors are visible to developers. You don't have to use the API keys or bridge group platform. All that stuff is optional. Checkups free. You can use it for lots of stuff. You thought you were done. That's one of the things that drives me. That's, I like pre-commit, but it's again, one of these things where it's like, I am leveled to go for lunch. I am not fixing security issues. So there can't be a lot of errors because pre-commit implies you waited to the end to commit. So if you did a lot of stuff then there could be a little bit of trouble there. So just as an intro, if you don't know pre-commit, I've got it here.  So if I look at cat.pre-commit config, I don't hit it twice, where I can see them in my pre-commit config. And by the way, this is part of my Git repo. So we're kind of like in a half way house now between ops controlled security and kind of a collaboration between ops and developers because as a developer I need to have the pre-commit installed on my local machine. Okay. Otherwise this gets ignored. However, this file can be in the control of security and ops to say what gets run. So we know we're now we're in a hybrid, very DevSecOps kind of situation. So it's going to go get the tools I need if I don't already have them, pinned to a certain version so everything stays consistent. It knows I'm using customize because that's the type of repo it is. So okay, cool. If I do a Git status, I can see that. Yeah, I did recently make some changes to this file deployment. Everything's okay. I don't really care too much about it. Okay. All right. Let's just do the one I've got right there. Let's clear that out and let's do let's commit that one. Demo for yeah. Okay, cool. And you notice as he needs to do some normalization of his pre-commit config, but that doesn't matter. It's still going to run check off just before I do this commit to make sure what I'm actually putting there passes the test. And it does not. Yeah, I was it. Okay. So this actually kind of looks familiar now. This is the same stuff that we saw earlier, except now it's in beautiful color. I do like that. We have the same help. And we have code segments because if there's a lot of different resources in one file, it actually highlights this is the resource specifically that had the problem. And I've got all the same things that I've got there before. Okay. Good. That's kind of good. But if we see all the things that got wrong, no, I waited a little too long. And I wouldn't even say I waited too long because this was a cut and paste from the internet. So I pasted it and went to commit it in and then right out of the box. It's like, no, you got to do a little bit extra work here before we're going to allow this in. Yikes. Certainly not going to get past CI. Definitely not going to get past the bouncer at the door of my Kubernetes cluster. Okay. But not bad. Everything's on my local system now. And I can see it all. So that's a plus. All right. And we did that already. Action number two. Command line. Very similar. Those all the same as you had in the previous one, right? You can see everything. It's all there. Granular security controls. All really good. Except command lines are optional. Now, the pre-commit, if you're doing everything right and you have it installed in that file that tells things, what tells you what's supposed to run as part of the get repo, that's part of a system, it's part of automation. Command line security is like, I hope you do it. But you kind of probably won't. Maybe not. That's not great. And again, if it's, if there's a lot to it, there can be a lot of errors. Also, you need to understand the command line options. Yeah. We didn't have to, we haven't even looked at that so far. And we've had lots of cool results, right? So let's come back over here and let's see. Let's take this.  Because it means, wow, this thing does everything. And oh my goodness, I've got to learn how it works. That's a disaster. I mean, the good news for this particular one is that it's generally easy. For the most part, you watch like a basic how to on this dash D means check everything below me. I don't even have to say what frameworks it'll just figure it out on its own. So it's both difficult and easy at the same time, like all command line tools. In this particular case, say I, I'm going to say framework. Yes. And there's customized right there. So I'm going to say just look, it's faster if you just say use the customize. This is what's here. There's no Terraform. I'm hiding in there. There's no Docker files, no serverless framework, just that one. And then you can fire it away. And it's going to understand this is customized. Fantastic. And then boom, I get everything. What's also cool is that now you remember the weird one that was in test that just didn't make any sense. If you tried to scan that with some tools that you use for YAML, it would look like garbage. It wouldn't work.  So I get my out of complete on overlays. Test. It understands in advance to combine them and use the customized present in kubectl to kind of create the manifest so that I only get the combined correct output. So that's also very cool and important. But I have the same thing I saw before. So it's just as difficult or as easy as it was. If I've only got one thing wrong, great. If I've got a lot of things wrong, it can be a big elephant to eat. Okay. Finally, hatch one. This is meant to be the friendliest hatch I could find. It looks like it doesn't even have a lock on it. And what I mean by that one is ID security or security on the fly. The pros of doing security in your ID is probably, as you already know, the same pros of doing like, well, what do I use for Python? I use cornflakes that runs Flake gate in the background. And it gives me all my Python problems. Or ESLint for TypeScript, things like that. You get the same level of granular security controls. You get all the stuff you can put in Git. You get errors conveniently visible to you and fixes. Now, this is a little caveat, right? I have to say and fixes because Checkoff does have the notion of providing instant fixes, particularly in the IDE. In fact, I think exclusively in the ID, also in the platform, but for developers right there, except not for Kubernetes yet. Some of the projects that we're working on, I'm working on it soon, coming soon. So I put it in there anyway. But we'll see evidence of it when we look at the ID in a moment. No need to learn the command line option. It says, oh, everything is kind of abstracted away. Yay. When you're done, you're done. These all sound good. What are the cons? I don't know. Seems easy. Let's get out of the command line. Let's go over here. Okay. So I'm looking at my base, deployment.yaml. If you can see it way down there, you see Checkoff scanning version 2.842 is the latest. We changed the version. It must be 100 times a day. It'll be at 900 by tomorrow. And if you're familiar with squiggly lines and VS code, by the way, we support JetBrains IDEs as well. Checkoff does, I think, most IDEs, tools. Try to support most things. You install it over here. It's there. It's easy to find. There's my cornflakes. There's my ESlan. Toss all the things you'd expect. And the squiggly line, you hover over and you know all those errors we just saw. Here they are again. Pretty cool, right? I can roll down. What do you know? And when I get to the bottom, you see where it said no quick fixes available. That's the coming soon that I was mentioning. We do have quick fixes for some things. But I got all the same stuff I did before. I can click on these and I can jump straight to the how-tos, learn how to do things, ensure my sec-comp profile is set to Docker default. Okay. I can click and learn about that. And I can start to make the changes I need to make in here to make that sort of thing correct so that ideally, I don't have any problems. That would be wonderful, wouldn't it? Let's just do a little quick one then. I don't have a security context either, which is also a rule that I shouldn't have one. And I'm going to do this here. So I've added a security context. I have sec-comp profile and I've set it to runtime default. That's me being a good boy. Now, we can see that I still have problems, but sec-comp was my second one and it's gone. Now, if I roll down, there used to be two security contexts because there is two. One of them is missing. So the one for containers is now present. So I'm chipping away actually at those 17 errors that I had. And I can slowly go through this and make sure my base is good to go. Now, this makes sense to have in my base. There's no reason why this wouldn't be there. It's not like it's special. It's not like for Dev, I don't want that. I might as well leave it there. If I go through all the steps, then we're going to get what we have here in prod. Prod is what we had in base, but has all the good security things added. I've got liveness probes. I've got limits and requests, which are often hard to figure out in advance. I have volume mounts so I can have read-only file systems, all the really good stuff. This is if you want to go get customized code because you just like want to see something that passes check off. You can see down here, there's a tick box saying, well done, Steve. No issues. Then that's there. So this is what we're trying to do is encourage developers on their desktop, even if you're using a weird framework like customized to transition yourself from what can often just be a default deployment to an example of what is a secure one and to do that with sort of NIDE helpers and help that allows you to both learn how to make secure code, but do it in your environment in advance so that you blow through all of those hatches. And that is, let me just go do one thing over here. Now, this is probably where I'm nearing the end and I think I'm looking at time. If I try and do a K apply dash K customize overlays broad, actually the service should still be there. It is. Okay, good. That should succeed. And I should, that evidence that that went all the way through CI, it's all there, it's all good. And it's now going to become persistent in my Kubernetes cluster. And I wasn't bothered by any of the nasty gates along the way. So that's kind of what I was kind of both create a little bit of empathy. There you go. We did it. How about that? Make sure it's not just sitting there saying crash it back off. I was not even there. Oh, it's still waiting. It's still waiting. Oh, well, we don't have to wait for it. The important thing I was trying to do is really make make developers and ops and create some empathy between them all so that you see like securities vision of this is, well, how can I get into automation or how can I avoid monitoring too much? How can I make sure that at least I've done all I can as early as I can to make sure that it goes? And conversely, the developer experience is that, well, if we can security vendors in particular, it's kind of vendors fault sometimes, because don't make it easy. But if we do make it easy like that so that you can learn about security, you can kind of have an education piece in there. And you know that, all right, this wasn't that hard. I made a security deployment and I know it's just going to fly through. We all win, right? All right. Well, we already saw it actually in summary. This configuration is our first class problems. Arguably more than the old hacker style application vulnerabilities. One little misconfiguration can cascade into all sorts of bad things as an attacker dies into the soft interior of your development pipeline. Infrastructure as code equals getups, get equals runtime, security and get is good. Defaults even from trusted sources are not always secure. Infrastructure as code security can and should be applied at all phases. The ideal is that all of those phases, all of those hatches are actually present even though in practice rarely are they all there. Defense and depth is good. And the reality is that the ROI, the easiest application for security is NCI. So at least expect that to be there. Security can be simple. Fixing infrastructure as code is super easy for everyone if we all do it together. Otherwise, they might get caught in CI or worse after A, the B word. Bad things happen. Okay. Thanks very much. I'm definitely out of time. I'm going to see if there's any questions in the chat. More information you can see down there. Richard, check off the customized goat, et cetera, et cetera. Thank you all for attending. Is Libby still there? Here. All right. All right. Anyone have any questions? Let's go ahead and pop them in the chat and we'll get to as many as we can. I will, I'll spend a bit more time on the one question. Oh, just check off a kind of wait list. I was going to go to the question about Terraform as a good one about it being in between declarative and imperative. But I'll just check off a kind of wait list. It does. It has a notion of suppression. So if you want to create, well, a few different ways, frankly, if you have a huge deployment, you can run check off baseline. And it will say, all right, everything I see, I'm going to consider that's in the past. It's technical debt.  So it's only looking for new problems. So that's one way of creating a wait list. Another way is that you can have hard fails or soft fails. You could just soft fail anything in the past. And then there's a notion of suppressions, which are supported inline or can be supported through the bridge group platform. Because if you are using the platform, you can have global suppressions like for your entire organization to say, never look for this thing because it doesn't apply to us. So yes is the answer in many ways. I'm going to check the chat. There's one more there. You're going to get a check in place redundant. Exactly. More right. Yes. Well, actually, I'm the big fan of Raghav who just said the more left, I'm going to say you go, the happier you'll be, the reality is having all the hatches in place is good because they're all going to be there, whether there are security controls there or not. As a developer, I don't know where they're going to be necessarily. I know certainly a bridge crew, we use pre-commit and we use CI for sure. So I use the ID and I make all the fixes. This is more of a personal experience. But more than likely, when you've got so many different personas involved, developers, ops, and security, they're all going to have their moments where they're going to add security and they will not necessarily care if there's already security in CI or you're already doing your desktop. So they are going to be in a lot of different places and there will be defense in depth ideally. So it's not so much as redundant as redundancy is a bad thing. It's kind of a good thing in security. Wow. Lots of questions now. Do we support custom resource definitions in communities like the elastic operator? Interesting. We could support the pending. That's a really big depends question because you can create custom policy. You can create policy both written in Python and you can create them using very simple logical YAML and we have like a little generator for doing that in the British Group platform. So if you've got something unique and there's a known security misconfiguration or misuse case that you can characterize, then you can create a rule that will check anything. Like for example, the one that we looked at earlier, the Kubernetes NGINX ingress, when that came out, well, that was new. That was unexpected. So we added rules like that day that made that happen. So it's possible to do just about anything in terms of what checks we need. There's a question about what about Terraform and work spaces? That may be a larger question to answer. Yes, we support Terraform. Terraform is the first language we ever supported. So our coverage for Terraform is quite extensive. So we can maybe, I can also say, if you're on the CNCF Slack, you can always find me there and you can ask me more direct questions. So let's throw that out there for questions that it might take too long. Yes, to the online programs channel too. So it's right up in there. Perfect. How can check up Helm with stacking ML configuration files? I think you're just saying can you handle, can check up handle Helm? Yes, is the answer. That's a very quick one. I think I'm going to say yes to that. Anything else? Maybe you'd have to use Slack more, Andreas. We're using Slack so much already. Instead of having any more. Did I miss any? Libby, did you see anything there that I didn't get? I think you got them all. All right. That was quick too. Yes, thankfully I know this product. I know how it works so well. I live it every day. There you go. Well, does anyone else? Last chance? Well, Steve, thank you so much. This was awesome. It sounds like you got a lot of good back and forth with everyone. And like I said, the Slack channel is in the chat right above. So be sure to click on that and y'all can keep it going. That's our online programs channel. So join it and keep the conversation rolling and we will see you next time. Thank you so much. Thanks everyone. Thanks Libby.