 Hello everybody. Happy Monday and welcome to OpenShift Commons. Today we're going to do another AMA briefing on a wonderful project, CubeLinter, brought to us from some of the folks at Stack Rocks. And we have Michael Foster here. He's going to introduce himself and his colleague Vishwa. And we're going to get an introduction to the project, where it's at, the roadmap, and have time for Q&A at the end. So without any further ado, Michael, please tell us all about CubeLinter, the community, and where it's going. Awesome, yeah. Thanks for the intro. Again, I'm Mike Foster. I'm a cloud native advocate at Stack Rocks, and I'm joined by Vishwa. Hopefully Vishwa give a hello. Hello everyone. Hey. And Vishwa is the lead maintainer for the CubeLinter project. So he's here to direct me if I get off course about anything. Vishwa is going to be my go-to guy as I would just walk through CubeLinter, talk to you about the community, demo its functionality, and hopefully have you joining the community after. So let's just get started. So again, what I'm going to cover, just going to go through an introduction, why we decided to create CubeLinter, where it fits into the ecosystem. Again, show you how to get started, download, integrate into your pipelines, just general workflow. So I'm going to show you how to use CubeLinter and the CubeLinter Lint functionality. I'll show you some of the more advanced features like configuration and configuring the policies and setting some flags so that we can ignore checks and enable checks. Lastly, I'm going to get into integration. So show you kind of where the real power of CubeLinter takes over as part of your CI pipeline. And we're going to talk to Vishwa about what's coming next in the pipeline, some issues with the project roadmap looks like for CubeLinter. And again, how you guys can all join in. I've already introduced ourselves, but again, that's Vishwa, I'm Michael, and I'll send some links at the end. So if you guys want to contact us or learn more about CubeLinter, we'll be happy to talk to you. So what is CubeLinter? So it's a CLI, right? It's a command line interface for Linting Kubernetes objects. These Kubernetes YAML files can be in the form of Helm charts. They can be just regular YAML files. And what we're going to do is we're going to use the default policies that are baked into the CLI to then let you know if there's some configuration mismatch, if you have elevated privileges and things of that sort. So because we have all these policies, we can configure certain policies, enable and disable them so we allow for some fine tune policy enforcement. And because it's a CLI, it's Go-Based, we have simplicity in design. It's something easy for you to integrate. It's a binary, right? Just download it, install it, add it to your CLI pipeline. Very easy to work with. And again, YCubelinter, because there's all these different policy options out there right now. And so we at StackRocks kind of saw that DevSecOps really wasn't catching on. And there's a reason for it. You can have all these tools, doesn't necessarily mean your developer's buy-in, doesn't necessarily mean it's easy to use. There's a knowledge gap, right? For some of these tools, maybe you have to learn another language. Though we wanted to keep the project simple, keep a relatively low knowledge gap in terms of being able to implement it. It is a Kubernetes-focused project. So some of the other policy applications are a little bit more wide in scope. This is for Kubernetes. So you know that that's what we're going to support. And that's what we're moving forward with in terms of policies and all our integrations. And really, Cubelinter is just there to identify misconfigurations as close to the source as possible, right? So we want to enable developers and CI pipelines to catch just issues as close as possible in a declarative way. And the checks are also there to give knowledge for further growth for users. So not only are we linting the files, but we're also showing you why the policy was created, documentation. If you're unaware of why the policy is there, you can go into Cubelinter into Kubernetes documentation and find out more. In the end, the end goal is that you can build operational policy, you know, within your organizations or teams. So something that can be implemented on a personal level, across a team or across an organization. And I'll show you how to do that. Okay, let's get started. I'm going to take a quick journey over to the Cubelinter project. So Cubelinter can be found on GitHub at Stackrocks in the Stackrocks GitHub repository, Stackrocks slash Cubelinter, where here you'll find everything that you need to get started. Vishwan and this team have done a great job at creating a dock site, which I personally like using a lot more. That's not dark mode for me. But yeah, so we have everything here installing Cubelinter, building from source, the usage, how to get involved in the community and the license as well. So again, you can install because to go binary, you can build using go, you can build from source. You can use a Docker container to run Cubelinter as well. And there's a bunch of other actions in here. So let's say you wanted to implement Cubelinter into your GitHub. And as a GitHub action, there's options for that as well. And a couple of demos that just examples that I'll showcase as well moving forward. Now, one of the big things that I want to show you before I go on to the C of the command line and showcase Cubelinter are the default checks. So Cubelinter has 19 default checks. And not all of them are enabled. There's 13 enabled by default. And Vishwan, correct me if I'm wrong, but really the reason for having 13 was we didn't want to overwhelm users. Not all these checks are necessary. And so we wanted people to be able to go use Cubelinter and see the core checks without being overwhelmed by all the errors. So, you know, focus on those core, you know, six to eight checks that tend to pop up. And then as you start to get more comfortable, you enable all the checks, and then you'll get things like, you know, unset CPU requirements, unset memory requirements, which aren't necessary, but should be enforced. Yeah, that's that was the there's some that, you know, we want people that we think we're opinionated and we're like everybody should follow them. And there's some that we know not everyone is going to be able to follow them. But these are like good practices. So we want the checks, but we didn't want we wanted them to be more up them. Yeah, just to add to what you were saying. Yeah, and the description and remediation in the checks also allow for you to run and run all the checks, you don't necessarily need to have an action on them, right? But it will showcase and help you move through it now. This will come up a little bit later too, as we get into customizing checks. But Cubelinter is built off of these templates that you can actually change and alter depending on your needs. So there is a required annotation check that basically just says, you know, you should have an email of some sort for somebody to contact you for this Kubernetes object, you know, we don't necessarily need that, but you can also alter it. So like, let's say you're a team, and you require an annotation of, you know, testing, or maybe you have if somebody's running an object, they need to put their name in as an annotation. You can set all that and configure the policies as you need them to. So there's some flexibility in what you can configure. Now, all I really have to show you the documentation because the real stuff is in the command line. So for this walkthrough, I've actually created a little demo repo, which has all the examples that I'm going to go through today, a few and we'll we'll post the the link up at the end as well if if you get lost. But yeah, so M foster rock slash Cubelinter walkthrough has all the manifest that I'm going to be going through today. And I'm going to be doing this in Visual Studio code. So in that repo, we have a list of manifests here. Now I've split it up in a weird way. People might be like, Why is there so many folders here? I did it to kind of showcase how Cubelinter works and works effectively. You could realize they could put all these demo files in a single file and just lint through them in one go. But we wouldn't really want to do that's not really doesn't really make sense and can't scale, right? So what I find really useful is Cubelinter lint lint everything underneath a folder, right? So we break it up, we apply the policies to each folder, respectively. Now just wanted to solve that question because it comes up kind of often. Cubelinter simple install I use brew to install it because I'm using a Mac right now. But it's very similar to Cubsetl, Cubelinter. It's going to have the available commands for me. There's the checks help lint templates and version command help is always there, you know, dash dash help dash h will always help you and give you a description as to what the commands are. Version is there to show you the version downloaded, obviously, and the checks and does you all of those default checks that I had showed you previously, right? So we have, like I mentioned before, the unset CPU requirements gives you description and remediation and a link as well if you want to find more documentation for more details. The other aspect here is the templates command. So just like the checks we have the templates command here. Now the differences is the checks are built off the templates, but the templates allow you to change some of the keys and values in the parameters of the check, right? Which I'll showcase more when we get to the config file. But just to kind of show the differentiation between what a check is and what a template is, the templates are there to help you build custom checks off of and the checks are the default ones that are built into kubelinter. Moving on to the good stuff. So we have kubelinter lint and we can technically lint and it will take all the YAML files underneath that folder. So because I have all the YAML files split up into all these different folders, you can see I have 54 lint errors. Now let's wait too much really to go through and check. So we probably want to be a little more specific about what we're linting. I have a couple compliance YAMLs in here and I have one that is non-compliant and I found eight lint errors. So what this YAML looks like is right here. So it's a non-compliant app. We have, for example, an AWS secret key that is in the YAML file should not be there. We have a server's account that doesn't match up in terms of labels. So there's and there's also what we're forgetting is there's a lot of information missing here. So we don't have un-set privilege access. We don't have any drop capabilities, any Linux capabilities that are set up. We don't have a UID or GID that are set here. So there's a bunch of other information that's missing, which if we go into the console, we will be able to see. So we, like I said, I ran the checks and these are the default 13 checks, right? And we found eight lint errors. This is not the default 19 or the total 19. So you can see we have an environment in our secret, you know, don't use raw secrets in an environment variable. Instead, either mount the secrets as a file or use a secret key ref. And then we showcase, you know, if you want more documentation, here's how you would solve this problem, right? Same thing. There's no read-only root file system. The remediation is, you know, set read-only root file system to true in your container security context and go from there, right? This it's pretty straightforward for that example. Now what I can also do is if I use the help flag, I can see the list of flags that are available to me using kubelinter lint, right? So I have a bunch of flags here. I have add all built in, I have config, I have do not add, do not auto add defaults, and I have the include. Now add all built in does exactly what it says it's going to do, right? It's going to add all those 19 checks. So originally we had 13, we want 19, we're going to do an add all built in. So you can do this directly from the command line. We can do a add all built in. And now we have 12 errors, right? So we've run six more checks against it. We've realized that it violates four of those default checks and these are going to be, yeah, so there's no memory request or limit set. There's no CPU request or limit set. Run is non-root, it's not set, for example. And, you know, one of the ways we can go through this is we could just tick them off one by one in here until we, you know, fix the issue. So something as simple as, hey, I got rid of this. Environment variable, run add all built in and I have 11 lint errors, right? One way to go about it. The other way, so you can do a do not auto add built in, you're going to get a warning, no checks enabled. Now one of the reasons why, and I've had this brought up a couple of times, is why did we even add that? Why did we add a do not auto add defaults? Like you're running the command, what's the point? Well, the reason is, is because you think we have 19 checks, we can either add all of them and disable them as we go down or we can, you know, disable all of them and include them as we go up, right? So if we say, maybe we really only care about running as non-root, maybe, you know, we just want to make sure that our containers are not running as root and if they are, we're flagging them for an exception, right? What we can do is, we can do a do not auto add defaults and then we can do an include string, include the run as non-root command, right? And so now I found one lint there. So really useful for flexibility. Now the next thing that's coming up is, why would I be doing this on my command line? I mean, you just see me like scroll up and down, go and copy and paste. It doesn't really make sense. It's not fast. It's not scalable, right? That's where config files come in. So instead of running something like this, I can use a config file in order to run the checks. I'll show you, for example, what that looks like. Now you saw the flag for the at all built in set to true. I can create a config file to basically run the same sort of flag and then I can also list all of my include and exclude arguments as well. For this config file, normally you'd have an exclude here. I've just commented it out. I have all these checks. They're all set to true. So I should get that 12 lint error message that I had before. Let's just make sure that I'm in the right space though. Biggs have eight, which should be 12 unless I'm skipping something. Maybe I have something that skipped out. But you can do the exact same thing with I have a do not auto add default set to true as well. So just like the other one, there's a do not add or there's an add and there's a do not add and I can run the exact same check against it as well as my formatting off here. Yeah, I'm just trying to figure it out that it's probably something like that. Yeah, I think it's probably like a tab or something like that that's off. It's because it's not. Yeah, so just as an example, we'll just say that I did all the checks. I can exclude specific checks. So if I was going back to the adult build-in, I have an unset memory requirement check there and the run is non-root. What I can do is I can tell the check to exclude and maybe we want to get rid of the run as non-root check. I can do that and then again everything's declarative. We want to comment things out when we make changes. So we're going to, you know, exclude the specific run as non-root check and we have seven errors. So if we go through, we'll see that that run as non-root check is not there now, right? And one of the reasons for the config file and being set up that way is the declarative nature of the ML files in Kubernetes objects, right? We want to use that declarative nature so that we can pass on information to other teams. So for example, let's say if a user was using kubelinter and you found out that that team and that microservice that they were working on had some specific requirements in terms of checks. Well, we can set up a policy around just kind of that baseline enforcement of checks and we just create comments to say, hey, you know, this specific operator or container or pod or something like that requires root access on the host and we can basically make a comment in the ML file and in the config file as well so the next person coming in understands why that decision was made. One of the interesting ways is because it's a CLI, you can really just apply it, can just route all the different folders. So not only do I need to do it to the non-compliant ML, but you basically can string all the commands together. So what I found really useful is to create kind of these default config files so you can see I have a couple examples here like maybe I have specific checks that I want for the cart's database down here. Well, I create a config file and then I just point the CLI towards that config file, check that folder and I have, I do it as a process of a couple steps in the CI process, right, with like a GitHub action or a GitLab runner or something like that. You can't always use config files though and there's always like specific exceptions. So instead of just having everything in the config file, we also wanted to give you the ability to comment things out in the, excuse me, in the YAML file as well. Just to showcase this, we have this ignore check annotation that allows you to ignore specific checks and document while you're doing it. And I'm kind of beating up on the run as non-route example here. For the example of this annotation, the, I'm going to actually take it out of here first, disable that. So hopefully you guys didn't get lost in that back and forth. Yeah, so we're back to eight lint errors, right, because I commented out the run as non-route. Now if I save this file, what I should get, I should get seven lint errors because I'm commenting out I'm telling you when to ignore this check and I want to ignore the run as non-route check. You don't necessarily need to write a description, however it's highly recommended you do. You can leave this an empty string, but the whole purpose was to allow users to document why they were ignoring checks or why they were disabling or enabling checks, you know, directly in the YAML file, right, and it's just one way that we can say, hey, we are, you know, avoiding this security process. We're aware that, you know, this is let's say not necessarily the best practice for securing our container, but this is required, here's why, getting contact with this person if you have any other questions, right, just to give you another example, let's say we, a developer would probably put this in just to not have any limits, but we can get rid of that and it got rid of two lint errors. The reason is because you're getting rid of memory requirements, high, a limit and a request, so we got rid of two errors there, and you know you can continue down, do CPUs, so I find it really a good workflow for, you know, looking at applications to have a config file that allows all the defaults enabled, and then you just go through and you just basically pick off and document exactly why you're making these decisions and do they need it, is there something I forgot to mention, right, and, you know, just simple descriptions in order to help you out. Now, I've got a question real quick. Sure. Is there a no excuses mode where you can't use any of those annotations or strict code? Yes, so that was actually brought up, there is not a you can't disable this mode, the, one of the things I brought up to Vishwa was because it basically defaults as a non-zero exit code, right, when it trips, so as part of like a CI pipeline, you technically could annotate your way out of no checks, right, so your developer could push something, check the way out of it, and you wouldn't be able to see it, so one of the things that's in the pipeline is basically so that even if there's an annotation for disabling it, it still prompts basically an output of like this is the check that was disabled in this YAML file, right, so that even if somebody did annotate it and somebody else was reviewing the work, they would still, it still trip a, trip a wire, but actually, no, there is not a, yeah, basically you're saying like you, you can't disable any of the checks, don't believe Vishwa, is there an option for that? No, but yeah, totally agree that we should add it. Yeah, adding it to the roadmap, that's a great recommendation, on to, cool, I was going to say, you go in and go and open up an issue. I can open an issue, I'll open an issue. Do it. All right. Well, yeah, we'll have it before the end of this, this session. Okay. All right, so moving on, we, so we basically just looked at all of the default policies, right, up until this point. The custom checks allow you, and this is one of the things that Vishwa has worked with, to enable some flexibility in the different objects that you can apply it to. Right now, a lot of the objects are deployments, there are a couple that are services, and, you know, as the project moves forward, it'd be interesting to get feedback from the community as to which objects and checks, you know, that they would like to see. So for some of the custom checks, for example, I find really useful for required annotation as a check. If I showcase that demo, sorry, the template, we'll see basically the options, the parameters that we can change in these checks. So here's the required annotation check, and we can see there's a flag not carrying at least one annotation, so it has to match the provider pattern. So basically, we can set the parameter and the key to, you know, kubelinter slash demo, for example. So if I went to the, I went to this non-compliant app, if there was no check that was kubelinter slash demo here, it would show the flag. Right, now I can set my own remediation that will come to the check, and you can, you know, add a bunch in there that you want or that you don't want. And what I found really useful about this is like now admins can enforce best practice for annotation throughout their YAML files. So no longer can somebody push something without their email attached to it or, you know, not actually, you know, adding the correct labels. So if you have like different, let's say you're in GitHub and you have different repositories for different teams or something like that, you have different config files for each team, all enforcing, you know, the exact same, or the exact same different annotations for each team so that you can like keep basically that, let's say, neatness across teams and then into your cluster. The other thing too is some of the parameters allow you to change the object kind. So this is an example where I'm specifying labels, but I want to specify labels to the service object kind, so it'll check. Basically the services, if I did it for carts, for example, it would check the service to say, hey, is the right label here? No, it's not. We need to make sure that that label is there. And, you know, it'll give you some sort of, oh, where did I just go? There you go, and it'll give you some sort of mediation. So please add environment label to service, dev test staging production, just as an example. Now what this looks like, and I have this as excluding basically everything, except for run as non-root, because that's what I'm picking on today. It's a tough Monday for run as non-root. I'm going to do the config eb carts, because that's the one we're looking at, and I'm going to do it against the, so you can see we have the checks. We have an at all built-in set to true, and we have this exclude, right? So we're excluding basically all the checks, except for run as non-root. And then we're implementing custom checks, which is a required label release deployment. We're calling, it's a specific name for this check, so we're calling the template is required label template, and then we're giving it a unique name. We're specifying the parameter, and the key that is changing, so there has to be an environment annotation there, and then please that environment label. So you do, you know, annotation, environment, semicolon, and then your explanation for which environment it is. So you can see, or semicolon equals on, you can see there's no label matching right there. And this is, I think, an example of both a, they're looking at the service, and we're doing required label release service. It's like a duplicate here. But yeah, either way, you can see that there's both checks that are coming out. And if I wanted to get rid of that check, for example, don't do. Really, it allows you a lot of flexibility to play around and configure your policies as you want it to see, as you want them. One of the, the biggest issues, especially from a security company like Stackbrox, that we've come across, is you hear this term shift left all the time, and nobody really talks about what shift left is, and it doesn't really matter if your developers see security as a, a big wall in front of them. You know, they're not really going to work with security. So what we wanted to do is we wanted to create a tool that is in the developer's hands that can be applied in an automated way as part of their pipeline, and also gives you a lot of flexibility. So let's say admins want to enable best practice onto their development team. Well, you can implement this as part of your CI pipeline without actually triggering a build fail just to give educational feedback to them. And I'll show you kind of what that looks like. In this repo, I have a GitHub workflow. So I have a config file for a GitHub action. Now, like I said, if you trip, if Cubelins are limped, trips in error, you'll get a non-zero exit code, which would technically, excuse me, cause your build to fail. Now, you don't necessarily have to fail it if GitHub actions, for example, allows you to continue on error, right? So depending on what branch you're working with, maybe your devs are starting off and they're new to Kubernetes, we don't necessarily need to have, you know, 54 lint errors and build fails all the time. So what we do is we run it with all the policies enabled and maybe we say continue on error is true, right? Then you have a meeting on Monday and you say, okay, well, I'm going to open up tickets because there's 54 lint errors and I want you to fix these eight before Friday, right? Doesn't necessarily, again, need to fail the build. But next Monday, when it comes back, we're like, did we fix those main security issues? Yes. Okay. Well, maybe we can fix two more, maybe we can fix five more, right? So we're not actually hampering developers, but it's just making those little changes in a way that, you know, kind of makes like allows teams to communicate and collaborate. In this example, I have basically two jobs. I have a test job and I have a staging job and the staging job fails when you run kubelinter lint. And what that looks like, if I go into GitHub actions, so I can see that the test phase worked. And one of the reasons why it's useful to, especially when starting off, have that kubelinter not fail is because a lot of the times when you're building these pipelines, if you get a non-zero exit code and it fails, you actually don't get to continue the pipeline. So in this example, I have two commands here. So I have like a lint and another lint because I want to apply different config files, right? Now applying different config files, this means that if this first command fails, the pipeline just stops. It doesn't continue through. So I found really useful to create a pipeline where it basically, it gives me all of the output, right? So I'm going into GitHub actions. I can come in here and I can see all of the output from both commands with different config files. I can then look at them, you know, go and have a conversation about what do I think are maybe the top two that we need to fix, right? Run as non-root, probably the top one. That's if it's not needed. So we can just prioritize. We can say, hey, I don't really care that much about your service not being labeled because it's in deployment. We'll fix it, but you really need to change this from run as non-root. And then you can push those specific policies down. And all we can do to do that is, well, you can set it so that it passes on tests, but if they want to move it to the staging branch or if they want to move it up, it's going to fail. So, hey, by the way, here's your feedback. If you want to keep going, you know, we're going to fail the build. So at some point you need to, you know, bring the hammer down as an admin and say, hey, this is not what we're doing. And one of the great things about, you know, implementing policy this way and sort of a, I guess, sunshine effect to it where we're just saying, hey, these are the policies that are getting tripped. You know, you figure out what to do with it is it allows us to build, you know, realistic security policies across your organization. So you have five teams, eight teams, 20 teams, they'll need to also go and say, hey, like what do developers need? You know, we'll give you flexibility in terms of how you can figure this, but then we also expect a little bit of just following best practice and we'll give you feedback as to what errors you're tripping and what we think you should focus on. Right? That was the goal of CubeLinter. One of the main reasons why we did it in the CLI phase is because Dacrox has Rock CTL, which is like an image scanner and all and gives you a lot more functionality towards just images in terms of further developers. So we have kind of those paired CLIs and which thought it was really useful to if we're going to be Kubernetes focused, here's your image scanning and then here's the configuration of the images in the cluster thought it was a good whole lifecycle approach. And then obviously when you get into the Stacrox, the sensor collector and more of the the user interface then you get whole lifecycle Kubernetes security management. So again, it's that first stop developer checkpoint for figuring out where your security vulnerabilities lie with Kubernetes and hopefully it gives you enough flexibility to be able to adopt and grow from there. Now, I think that's Vishwa, did I miss anything of major importance? Any functionality? Nope. Thank you. Got everything. So thanks, Foster. I'll hand it off to you. You have the roadmap which it sounds like we need a we have a new issue coming in. So we should add that to the roadmap. Yes, I just saw that. Cool. Cool. So, hey everyone, again, I'm Vishwa and I'm one of the engineers working on Kublinter and thanks, Foster, for going over that demo. I'm going to be giving you a high level overview of the things on our like near to medium term roadmap. So, obviously one big component of what we're adding is more checks. And there's a few different things here. There's like one there's like more checks along the lines of what we've written. Another is a feature request we've heard from some people is to have some checks that map specifically to certain compliance checks and allow and not just add those checks but allow some way of tagging checks with metadata as to like these checks will help you. These checks are required for you to be in compliance with this standard and things like that. We want to consider additional resources that we don't yet consider in our checks like network policies pod security policies and things like that. And like checks based on those so a simple check could be like does your deployment have a network policy? And if it doesn't it should because otherwise it can talk to anything and more complex checks could be allowing people to to write like more fine grained rules on network policies like you know don't allow network policies that are overly broad or whatever they want. And so that's like something we're thinking of. Another one big one that we've heard is custom resources. Right now we support like all our checks basically work only on like native Kubernetes objects like deployment services demon sets and things like that. But you know with the latest versions of Kubernetes like custom resources are becoming a bigger and bigger thing and we're trying to figure out what's a good way to support them. And this also includes and it's not in addition to custom resources there's like other things like you know OpenShift for example has its own resources like security context constraints and deployment configs and that's another thing we would want to support as well. Another is better customizability. So as as you saw in the demo you currently allow you to specify checks through basically having these templates that we provide and allowing you to like parameterize those templates. But we are thinking of ways to allow more flexible specifications of checks for cases where that works because right now if you want to write a totally new kind of check you will need we will need to update go code and like release a new version of kublinter which is not ideal. So we're still figuring out how to design this but you know some ideas are the simplest on the spectrum is like something like using you know like JSON parts allowing people to specify JSON parts or something to say like this this field in the YAML should be equal to this whereas a more complex thing along the spectrum would be like allowing people to put in you know rego policies and use what they use in OPA with kublinter. Another big few things that we want to do are like usability improvements. There's a bunch of things around this that on our roadmap but some of the ones that they're thinking of automated rewriting in cases where it's possible like obviously it's not going to be possible everywhere because in many cases we can just tell you like something's missing and you need only you know what is to be added but in there are some cases where things on our own are similar to what many linders do and that's something we would want to support and then more convenience command line flags so you know people have asked us there's a few requests on this and we've added some like some of the command line flags you saw Michael use were added in response to use a feedback but people have asked us for things like you know I was to ignore certain parts easily and things like that so we there's like a bunch of those usability related things that we need to do and then finally and I did see there was a question about this we really want to do native integrations so that's two big buckets like one is with IDEs so you know VS code is I think the one we've got the most request for we would also probably do IntelliJ and you know the JetBrains family as well as Lens which is Mirantis is open source Kubernetes IDE and we think that's a good fit for something for us to integrate with as well and have been in conversations with them because they very recently released like an API that makes it easy for you to integrate with it and then CI systems you know we do have a GitHub action that we publish but we do want to make it easier to just drop it in to like CircleCI or Jenkins and things like that it's right now it's not terribly hard to use because it's just a binary and you can download it and then or run it but we in my experience like the easier you make the more pluggable you make these things the more it just removes a lot of friction and makes people much more likely to use them so Yeah, Vishwa you and I Yeah, worries you and I have talked about creating a repository with a bunch of basically best practices right like I I have six config files in that repository I think it'd be very useful to to kind of showcase like hey here's some you know default config setups that you can use along with different actions whether it be like GitLab Jenkins GitHub as well so Yeah, yeah, absolutely we should definitely add that to the roadmap Yeah, yeah, absolutely Thanks Michael that totally agree um problem Yeah, so that's that's a little that's a high level overview of the roadmap and our roadmap is managed entirely on our GitHub so we use GitHub projects which allows us to basically use GitHub issues as tickets and then put them put them in this context of the roadmap yeah so I guess Michael is showing you Yeah, all right you can see and we you know where as people file issues we typically add them to the roadmap or deduplicate them and like update another ticket and that's so that's what they're using to to manage look at Paul he Yeah, thanks Paul that's awesome he snuck right in there yeah that was that was a very quick issue open like that got that number 128 too BAM yeah nice round number very pleasing yeah all right anything anything else Vishwa that you wanted to chat about just yeah I think the last slide was just about like helpful links but you know we already went over those but maybe just maybe maybe just forward one more yeah so definitely will yeah so this is the link to our GitHub which you which I think some people have posted in the chat already to link to Paul's issue we also have a docs website that Michael showed you we you can also communicate with us by you know filing issues for sure and sending PRs but you can also join Kublinter on Slack and then and for the link to join the Slack is on the GitHub so if you just go to the GitHub page and search Slack we have an invite link that you can use and we'll take you right into our our Slack workspace and all of us are on it and you know we try to be pretty responsive so if you have if you just want to like talk to us about anything like that's probably the lowest friction way for you to reach us and yeah try the Kublinter walkthrough that Michael has put together so you know we like in closing we are not this is probably the first not the very first but this is among the first open source projects that you know we've done at Stack Rocks we and they're like learning a lot about this as we go through with this specific project and we we've been happy with the response we've received so far and we're looking forward to engaging more with users and trying to figure out like how we can make this a better project that's like more useful to our community so definitely looking forward to hearing from you I think one one thing was specifically interested in as you know how are how are people using it I think we've we found that people do file issues when they run into bugs so when they have feature requests but it can sometimes be hard to figure out like is this are these just like the tip of the iceberg of people using it and like there are many people who use it but don't actually get around to filing issues and so any I guess what I'm trying to say is like any input on how you're using it is welcome even if you don't have like a concrete suggestion or request just because that's interesting to for us to hear about but that I think that's the end of our our presentation so thank you for listening and I guess we'll take questions now awesome thanks one thing do you have any open community meetings set up yet or anything like that or are you still just mostly doing it through the the mailing list and issues connecting with your end users and folks is there but yeah so we have of the just getting started on doing that so we actually have an AMA that's coming up believe on this 16th is that right Michael I think so don't call me on that I'll look it up right now as you're as you're going on yeah that's that's going to be a first 40 into this so I can I can just pull up the link and post it on the chat it's just after this but yeah that's going to be our first 40 but until now it's just been slack and guitar okay and so for the most part it's stack rocks engineers working on this yeah we've received a few contributions from users but we are you know and we are most of the contributions have been internal so far and you know the PR like approvals and merging is currently just stack rocks engineers right now well it seems and I was talking with Michael a little bit before everybody got talking today and we hit the record button about how this seems like a nice complimentary thing to what you have for products as well the products are more based on examining images so you know I would think that this fulfills you know a need for this this piece of the work and I was just wondering how this relates maybe to operators because we talk a lot about using operators versus Helm charts and YAML files there is is there any work going on Vishwa around the operator framework or examining that not not specifically like we haven't we haven't done anything specific to operators here of we again like since we're analyzing the YAML files to some degree you know if you if you are able to render the operator into a YAML file into like it's final YAML files like the tool will work but yeah the things that we are we focused on at least at the beginning have been better support for Helm charts so with Helm charts we we don't require users to render them like we kind of use the Helm libraries under the hood and if we detect that it's a Helm chart we just automatically like render the YAML the templates and I don't know checks on them and another thing we've heard requests for is customize as well with some people use to manage their configs but yeah that's a good suggestion and something for us to look into yeah it would be interesting to see how that works there have been a couple of things that have come up in the chat Noel has a list of issues that he's seen other customers from his perspective and I love the acronym over my dead body I don't know Noel if you want to share that list with them and walk through that a little bit have to unmute you go there if not and you probably got that other question covered with a VS code in your road map talk and the other question I think was around comparing what you're doing with CubeLinter with what goes on in OPPA the open policy agent can you talk a little bit about that? yeah so that's that's a really good question and it's something you know we we've thought about as well I think we concluded that like we ended up building this because we found that for us internally so this actually came out of like internal pain points that we had that's that was like the initial you know like spark of us building this and then that later you know we decided that this could be something we open source but with OPPA and CONF test like you can achieve many of the same results but we we found that this what we're building here is more focused on Kubernetes and that's that allows us to do that allows us to do some things which are more Kubernetes natural like for example the way we ignore checks by annotations for example like we've been able to build that into the tool because we have this assumption that we are working on Kubernetes YAML files and the another one is how we are building native support for hand charts and we're just like if you see a hand chart we just render it like our tool is more Kubernetes aware so I think that Kubernetes awareness is one big thing that we felt that we could do in a custom tool and the other thing is we also are kind of opinionated about certain defaults checks that you know we wanted to enforce internally and we figured that it would be nice to have those like built into the tool so that if someone downloads it they don't need to with CONF test and OPPA there are like rule sets available but we wanted to make it something where like we also kind of guide users to what's saying like these are the tools that we think should be enabled by default and they're actually built right into the binary so those are the couple of reasons we decided to build something something different and we do I do still think that the OPPA language is very powerful much more powerful than you know the kind of language we've built but that comes complexity but we're also thinking of a ways to make our ways to like use the OPPA language in our policy configuration so like I mentioned the roadmap we're thinking of ways to make more flexible policies and one of the ways we could do that might be like allow people to specify rego files and so essentially for people who want that added flexibility they get that right and coob linter but they also get the convenience of you know all our other coo specific features so hope that answers the question answered mine I hope it did for everybody in the chat as well and Noelle Noel I think you've got your speaker fixed your microphone could you hear me now I can hear you now there you go yeah perfect so I put those lists of things together over the last while because it's what we're seeing with very large customers of OpenShift is it's not necessarily the developers that are struggling with these things it's it's large operations teams or even small operations teams that have a large number of third-party either vendor applications or in-house development teams where they spend the majority of their time getting stuff onto the cluster and then spend the rest of their time trying to figure out what's gone wrong so things like missing readiness probes and all that type of stuff and especially in the FSI space we've seen things around you know when you you're working in service mesh is MTLS enabled on service mesh or not so it's kind of more granular things but it was around basically how do we enable those customers to actually kind of set up kind of standards that have to be enforced do you know what I mean for to get the application out there so the kind of if you if you think of like things like SonorQ for code this would be the equivalent for for Kubernetes or OpenShift resources you know that's the kind of stuff we've seen so far yeah this is a very thorough list too of policies yeah and a lot of these checks are actually implemented in kubelinter and the other thing too is obviously stackrocks is a more complete you know security tool that basically looks at all these checks and allows you to enforce either as part of the pipeline or in the cluster right yeah so it's I don't know if if that's like a subtle me just saying hey like the stackrocks basically does a lot of the stuff yeah it does yeah yeah listen here so yeah no it's it it's good and it's actually great to hear that the developers aren't the ones having an issue I've I've always found when I've been working with customers especially like an consulting rule it's it's just the issue of like fine-tuning policy across different teams right it's it's the admin aspect of kubernetes because the multi-tenant when you get multi-tenant setups it just becomes a little more complicated so a lot of our tools are focused around users but users at scale right because security only really works when people buy in and so we want to make sure that the tools are set up so that we're not just kicking people out of the cluster we're you know it's more of a security observability tool with the ability to enforce policies right that's that's the goal but yeah this is really cool repo thanks for sharing this Norris yeah second that Noel it's really useful and we're definitely going to be looking at that to steal ideas for kubernetes so thanks for sharing I'm going to say giving us issues and and giving us ideas what is this Noel you want to come join the team keep it it sounds like a game plan here this is great it also sounds you talk Mike a little bit about having some best practices config files as well so setting up sort of recipes and cookbooks for people to to use as best practices in their own organizations and I think maybe some of what Noel is listing here are our best practices things were for different platforms that were were deploying to so it's actually some really cool work to go through and collaborate with you guys on so yeah this is awesome yeah we're almost to the end of the hour I'm not seeing any more questions in here I'll I'll ask the one out there Hugh Blinter is there any plans for sandboxing it into CNCF where you know what are the the next steps for you guys as a project yeah we we actually don't have a great answer to our long-term plans just because we have just been focused on the short and medium term so far I think we've kind of been focused on just the project is only three-ish months old at this point since we released it and so we've just been kind of focused on understanding like how are people using it and trying to make improvements to it and I think you know when we released it we didn't know what to expect whether like nobody would care or whether like people would use it and we've been happy it's exceeded our expectations for like people have been interested and have been using it and I think you know now is a good time to think about things like that again this is something we don't have a ton of experience with at StarCross because this is our biggest open source project and so I think it's just something we need to figure out but yeah to answer your question we haven't given that a lot of thought so far to be honest well it looks like from the interest in it today and the work that you've done you're on the right path so I think you'll think we're gonna follow you guys actively and see and see how this goes and have you back again with the next release of it so this is awesome so um thanks very much for coming today it we totally appreciate the the overview and the deep dive into it and look forward to working with you guys more on this so take care everybody and then I will post this video and the slides up shortly to the YouTube channel awesome on OpenShift so yeah thanks and along with Noel's list of suggestions there so awesome thank you so much for having us it was yeah thanks so much for having us Dianne it was great and thanks for listening everybody and for your engagement to your questions