Red Hat OpenShift Security | OpenShift, 8 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: KubeLinter Introduction and Road Map Viswajith Venugopal Michael Foster (StackRox) OpenShift Commons

Description

KubeLinter Introduction and Road Map
Guest Speakers: Viswajith Venugopal and Michael Foster (StackRox)
Hosts: Diane Mueller and Paul Morie (Red Hat)
OpenShift Commons Briefing
#AMA
2021-02-08

A

Well, hello, everybody happy monday and welcome to openshift commons today we're going to do another ama briefing on a wonderful project, cube linter brought to us from some of the folks at stackrocks, and we have michael foster here, he's going to introduce himself and his colleague bishwa 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 and where it's going.

B

Awesome yeah thanks for the intro again, I'm mike foster, I'm a cloud native advocate at stackrocks and I'm joined by vishwa. Hopefully, bishop will give a 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, uh ish was gonna, be my go-to guy, as I would just walk through cube linter talk to you about the community demo, its functionality and uh hopefully have you joining the community after so, let's just get started so again.

B

What's what I'm going to cover just going to go through an introduction, why we decided to create cube linter 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 cubelincher in the cubelinter link functionality I'll show you some of the more advanced features like configuration and configuring, the policies and uh and setting you know some flags so that we can ignore checks and enable checks.

B

Lastly, I'm going to get into integration so show you kind of where the real power of cubeblender takes over as part of your ci pipeline and we're going to talk to vishwa about what's coming next in the pipeline, you know some issues. What the project roadmap looks like for cubelinter and again how you guys can all join in already introduced ourselves, but again, that's vishwa.

B

I'm michael and I'll send some some links at the end. So if you guys want to contact us or or learn more about cubelinter, we'll be happy to talk to you.

B

So what is cubelinter 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 uh yaml files and what we're going to do is we're going to use the default policies that are baked into the cli.

B

But then let you know you know if there's some configuration configuration mismatch, if you have, you know 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-tuned policy enforcement and because it's a cli, it's go based. We have simplicity and design, something easy for you to integrate. It's a binary right, just download it install it. Add it to your ci pipeline very easy to work with.

B

And again, why cube linter? Because you know there's all these different policy options out there right now, and so we at stockrocks kind of saw that devsecops really wasn't catching on and there's a reason for it. You know you can have all these tools doesn't necessarily mean your developers buy in, doesn't necessarily mean it's easy to use. There's a there's, a knowledge gap right for some of these tools.

B

Maybe you have to learn another language, so 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 focus 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 we're moving forward with in terms of policies and and all our integrations and really cube. Blinter is just there to identify misconfigurations as close to the source as possible right.

B

So we want to enable developers and ci pipelines to catch just issues as close as possible in a declarative way, and the the checks are also there to give knowledge for further 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 cubelint into kubernetes documentation and find out more in the end. The end goal is that you can build operational policy.

B

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.

B

Let's get started, I'm going to take a quick journey over to the cubelinter project.

B

So cubelauncher can be found on github at stackrocks in the stackrock's github repository dacron cubelinter, where here you'll find everything that you need to get started.

B

uh Vishwan and the team have done a great job at creating a a doc site, which I personally like using a lot more.

B

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 it's a go binary you can build using go, you can build from source. uh You can use a docker container to run keyblender as well and there's a bunch of other actions in here. So let's say you wanted to implement cube linter into your github as a github action.

B

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: the command line and showcase cube link. There are the default checks, so keyblender has 19 default checks and not all of them are enabled there's 13 enabled by default, and this will correct me if I'm wrong, but really the the reason for having 13 was. We didn't want to overwhelm users.

B

Not all these checks are necessary, and so we wanted people to be able to go, use, cube, linter 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.

C

That's this there's some that you know we want people that we think we are opinionated and we're like everybody should follow them and there's some where 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 opt-in, yeah. Just to add to what you were saying.

B

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.

B

This will come up a little bit later too, as we get into customizing checks. But keyblender 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.

B

So, like let's say your 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.

B

You can set all that and configure the policies as you need them to so there's some 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.

B

So for this walk through 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 cube winter 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.

B

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? um I did it to kind of showcase how cube linter works and works effectively.

B

You could realise that they put all these ammo files in a single file and just link through them in one go, but we wouldn't really want to do that. It's not really. It doesn't really make sense and can't scale right. So what I find really useful is cubelinterlint lends 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 people enter simple, install.

B

I use brew to install it because I'm using a mac right now, but it's very similar to cubectl cubewinther. 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. H will always help you and give you a description as to what the commands are version. Is there to show you the version that you downloaded obviously.

B

And the checks.

B

And shows 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, a remediation and a link as well. If you want to find more documentation for more details,.

B

The other aspect here is the templates command.

B

So, just like the checks, we have the templates command here now. The difference 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 before we get to the config file, but just uh to kind of show the differentiation between what a check is and what a template is.

B

The templates are there to help you build custom checks off of and the checks are the default ones that are built into cubelinter, all right, I'm moving on to the good stuff, so we have cubelinterlint and we can technically lint and it will take all the yaml files underneath that folder. So um because I have all the yaml files split up into all these different folders, you can see. I have 54 linked errors.

B

Now, that's way too much really to realistically go go through and check, so we probably want to be a little bit more specific about what we're lending. So I have a couple compliance yamls in here and I have one that is non-compliant and I found eight linked errors.

B

So what this yemo looks like is right here, so it's a non-compliant app.

B

We have, for example, an aws secret key that is in the emo file, should not be there. Now we have a service account that doesn't match up in terms of labels.

B

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 uns that you know privilege access. We don't have any uh 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.

B

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 the total 19.. So you can see we have an environment, var 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.

B

The remediation is, you know, set read-only root file system to true in your container security context and go from that 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 cubelinterland right. So I have a bunch of flags here. I have at all built in I've. Config I have do not add, uh do not auto add defaults, and I have the include now at all built in does exactly what it says.

B

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.

B

Idle build pin, 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 yep. So there's no memory request or limit set, there's no cpu request or limit set uh run is not. Root is not set, for example, and you know one of the ways we can go through this is we could just take them off one by one in here until we, you know, fix the issue so something as simple as hey.

B

I got rid of this environment. Variable don't add all built in, and I have 11 win pairs right.

B

One way to go about it, the other way, so you can do a do not auto add built in.

B

You're gonna get a warning, no checks enabled now one of the reasons why and I've had this brought up a couple times is: why do we even add that? Why do we add a do not auto add defaults, like you're running the commands? 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.

B

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 exclude string.

B

B

The run is non-root command right, and so now I've found one lid there so really useful for flexibility. Now, the next thing that's coming up is. Why would I be doing this online command line? I mean you've. Just seen 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, show you, for example, what that looks like now.

B

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 pigs.

B

I have eight, which should be 12.

B

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 ad and there's a do not add, and I can run the exact same check against.

B

B

Which was my formatting off here.

C

Yeah, I'm just trying to figure it out, but it's probably something like that.

B

Yeah, I think it's probably like a tab or something like that. That's.

B

Off 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 built in, I have an unset memory requirement checked there and the runner is not root. What I can do is, I can tell.

B

The check to exclude- and maybe we want to get rid of the runner's non-root check- I can do that and then.

B

Again, everything's declarative. We want to comment things out when we make changes, so we're going to you know, exclude this specific run as non-root check and we have seven errors. So if we go through we'll see that that run is not root, check is not there now right and one of the reasons for the config file and being set up like that way is the declarative nature of yaml files and kubernetes objects right. We want to use that declarative nature so that we can pass on information to other teams.

B

So, for example, let's say if a user was using cube linter 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.

B

So the next person coming in understands why that decision was made.

B

One of the interesting ways is because it's a cli, you can really just apply it just throughout all the different folders. So not only do I need to do it to the non-compliant yaml, 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 database down here.

B

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 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, the 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 emo file as well.

B

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 I'm kind of beating up on the run as non-root example here for the example of this annotation, the I'm going to actually take it out of here. First.

B

B

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: that's not root!

B

Now, if I save this file, what I should get, they should get seven lint errors, because I'm commenting out, I'm telling cube, went through ignore this check and I want to ignore the run as non-root check.

B

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 for to allow users to document why they were ignoring checks or whether 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.

B

Here's why get in contact with this person? If you have any other questions right.

B

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 I is because you're getting rid of memory requirements high uh a limit and a request, so we got rid of two errors there, and you know you can continue down do cpus.

B

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.

A

I've got a question.

B

Real quick sure is there a no excuses mode where you can't use any of those annotations? Yes, so that was actually brought up. There is not a you can't disable this mode. The one of the things I brought to visual 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 their way out of it and you wouldn't be able to see it.

B

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's still trip triple wire, but actually no, there is not a yeah, basically you're, saying like you, you can't disable any of the checks. I don't believe vishwa. Is there an option for that?

B

C

But yeah totally agree that we should add it.

B

Yeah, adding it to the roadmap. That's a great recommendation.

B

All right on to cool, I was going to say, you're going to go and open up an issue I'll.

D

B

D

B

Well, uh yeah we'll have it before the end of this uh 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 that visual 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.

B

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 for the sorry, the template.

B

Let's we'll see.

B

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 cube linter demo, for example. So if I went to the key I went to this non-compliant app if there was no check that was cube, linter demo here it would trip the flag right now I can set my own remediation.

B

That will come through 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 for other 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 on github and you have different repositories for different teams or something like that.

B

You have different config files for each team, all enforcing you know the exact same ana, 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.

B

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.

B

There you go and it'll give you some sort of remediation, so please add environment label the service dev test staging production, just as an example.

B

Now what this looks like- and I have this as excluding basically everything except for run- it's not root, because that's what I'm picking on today, it's a tough note monday for run is non-root.

B

I'm gonna do the config eb cart.

B

Because that's the one we're looking at and I'm going to do it against.

B

C

B

So you can see we have the checks, we have an add all built in set to true, and we have this exclude right, so we're excluding. Basically, all the checks, except for run, is not root and then we're implementing custom checks, which is a required label, release deployment, we're calling the it's a specific name for this check. So the 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.

B

So there has to be an environment uh annotation there and then, please add environment labels. So you do you know annotation environment semicolon and then your explanation for which environment it is so you can see or semicolon uh equal sign.

B

You can see, there's no, uh no label matching right there, and this is, I think, an example of both a look at the service and we're doing require 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, two really it allows you a lot of flexibility to play around and configure your policies um as you want to see as you want them.

B

One of the the biggest issues, especially from a security company like stack, rocks 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 big wall in front of them.

B

You know they're not really going to work with security, so we wanted to do is want to create a tool that is in the developers, 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 develop 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.

B

I have a github workflow, so I have a config file for a github action now, like I said, if you trip, if keyblades are limped trips and air you'll get a non-zero exit code which would technically excuse me cause your bill to fail. Now, you don't necessarily have to fail it. If github actions, for example, allows you to continue on air right so, depending on what branch you're working with, maybe your devs are starting off and either new to kubernetes.

B

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.

B

Then you have a meeting on monday and you say: okay. Well, I'm going to open up tickets because there's 54 length errors, and I want you to fix these eight before friday right. It 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.

B

Maybe we can fix five more right, so we're not actually hampering developers, but it's just making those little changes um in a way that you know kind of makes commun like allows teams to communicate and collaborate I've. 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 cube enter lens and what that looks like if I go into github actions.

B

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 cube. Linter not fail is because a lot of the times when you're building these pipelines. If you get a non-zero exit code, it fails, you actually don't get to continue the pipeline. So in this example, I have two uh two commands here, so I have like a lint and another lens, because I want to apply different config files right now applying different config files.

B

This means that if this first command fails the pipeline just stops, it doesn't continue through. So I found really interesting 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. I can see all of the output from both commands with different config files.

B

I can then look at them. You know go and have a conversation about what I think are. Maybe the top two that we need to fix right run is non-root, probably a top one, especially 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 when it's not root, and then you can push those specific policies down and what we can do to do. That is well.

B

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 to build. So at some point you need to, you know, bring the hammer down as an admin and and say hey.

B

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 all- have different- needs right and employing a one size. Security policy across those teams is just it's. It's a hindrance.

B

It's not going to help your developers they're, going to end up, not liking your security team, but we, as you know, if you're going to be security focused, you need to also go and say: hey like what do developers need. You know, will 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.

B

That was the goal of cubelinter. One of the main reasons why we did it in the cli phase is because doc rocks has rock ctl, which is like an image scanner and all and gives you a lot more functionality towards just images in terms of for the developers. So we have kind of those paired clis and we 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.

B

I thought it was a good whole life cycle approach and then, obviously, when you get into the stack rocks the sensor collector and- and you know more of the 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 it and grow from there.

B

Now I think, that's bishop did I miss anything of major importance. Any functionality.

C

Nope, thank you, god everything. So thanks foster.

B

I'll hand it off to you, you have uh the road map which it sounds like. We need a. We have a new issue coming in, so we should add that to the roadmap. Yes,.

C

I just saw that uh cool uh cool, so hey everyone uh again, I'm vishwa and I'm one of the engineers uh working on coop linter and uh thanks foster for going over that demo. uh I'm gonna be giving you a high level overview of like the things on our uh on our like near to medium term uh roadmap.

C

uh So, obviously, one big component of what we're adding is more uh more checks uh 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 of feature request. We've heard from some people is to have some checks, that map specifically to certain uh 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.

C

uh These checks are required for you to be in compliance with this standard, and things like that. um We want to consider additional resources that we don't yet consider in our checks, um like network policies, uh port security policies and things like that uh and like checks based on those. So a simple check could be like.

C

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, a big one that we've heard is custom resources uh right now we support, uh like all our checks, basically work. Only on um like native kubernetes objects like deployment services, demon sets, and things like that.

C

uh 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 uh to support them, uh and this also includes- uh and it's not additional to customer resources. There's like other things like you know. Openshift, for example, has its own resources like uh security context, constraints and deployment configs, and that's another thing we would want to support as well.

C

um Another is um better customizability so, as as you saw um in the demo you we currently allow you to specify checks uh through basically having these step.

C

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, um 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 kubelinter, which is not ideal so where we're still figuring out how to design this. But you know some ideas are uh the the simplest on the spectrum is like something like using.

C

uh You know, like json paths, allowing people to specify json paths or um something to say like this. uh This field in the yaml should be equal to this, uh whereas a more complex thing along the spectrum would be like allowing people to put in you know regular policies and use what they use in oppa uh with kubelander.

C

um Another big few things that we want to do are like usability improvements or there's a bunch of things around this that on our roadmap, but some of the ones that we're thinking of uh automated rewriting uh in cases where uh 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, uh but in there are some cases where we can fix things on our own, um similar to what many lenders do and that's something we would want to support uh and then more convenience command line flags.

C

So you know people have asked us, there's a few requests on this and we've added some uh like some of the command line. Flags you saw michael use were added in response to user feedback, but people have asked us for things like you know, allow us 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 uh do uh and then finally- and I did see there was a question about this- um we really want to do native integrations.

C

uh So that's two big buckets like one is with ides, uh so you know vs code is, I think the one we've got the most requests for.

C

uh We would also probably do intellij, and you know the jetbrains family as well as lens, um which is mirantis's open, source, uh kubernetes uh 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 uh and then uh ci systems.

C

uh You know we do have a github action that we publish, but we do want to make it easier to just drop it in or do like circle, ci or jenkins, and things like that. It's right now.

A

C

Not terribly hard to use because it's just a binary and you can download it and then run it, but the the in my experience, like the easier you make, the more plugable you make these things the more uh it just removes a lot.

D

C

Friction and makes people much more likely to use them.

B

C

B

I yeah no worries you and I have talked about um 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 um along with different actions, whether it be like gitlab, uh jenkins, github as well so yeah yeah. Absolutely. We should definitely add that to the roadmap.

C

Yeah yeah, absolutely thanks, michael uh that totally agreed 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 uh put them in this context of a roadmap um yeah.

C

So I guess michael, is showing you yeah all right.

B

You can see.

C

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 the that's. What we're using to to manage.

B

Look at paul, he yeah.

A

He snuck right in there.

B

Yeah, that was that was a very quick uh issue open thanks for.

D

B

Number 128, too bam. Yeah nice round number very pleasing, yeah, all right um anything. Anything else, vishwa that you wanted to.

C

uh Just yeah, I think the last slide was just about like uh helpful links, but you know we already went over those, but maybe just maybe maybe just forward one more yeah so definitely well yeah. So this is the uh link to our github, of which you, uh which I think some people have posted in the chat already to link to a paul's issue. uh We also have a doc's website that michael showed you uh we, you can also uh communicate with us by.

C

uh You, know filing issues for schwa uh and uh sending prs, but you can also uh join kublenter on slack uh and uh they'll and for the link to join the slack is on the github. So if you just go to the github page and search uh slack, we have a invite link that you can use and we'll take you right into our slack workspace and all of us are on it and you know we try to be pretty responsive.

C

So if you have, if you just want to like talk to us about anything like that's, uh probably the lowest friction way for you to reach us um and yeah. uh Try the kubelinter walkthrough. That uh michael has put together. uh So you know we uh like in closing, we are uh not. This is probably the first, not the very first, but this is among the first open source projects that you know.

C

We've done at stack rocks we uh and like learning a lot about this as we go through with this specific project, uh and we we've been happy with the response we've received so far uh and we're looking forward to engaging more with users and trying to figure out like how we can make this uh a better uh project. That's like more useful to our community. So definitely looking forward to uh hearing from you. uh I think one um one thing we're specifically interested in is you know how are how are people using it?

C

uh I think we've we found that people do file issues when they run into bugs or 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.

C

So any uh I guess what I'm trying to say is like any uh 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, uh but that I think that's the end of our uh our presentation. So thank you for listening and I guess we'll take questions now.

A

Awesome um thanks. uh One thing: do you um have any um open community meetings set up yet or anything like that? Are you still just mostly doing it through the the mailing list and issues um connecting with your end users and folks? There.

C

Yeah, so we have uh we're just getting started on doing that, so we actually have an ama. That's coming up. uh I believe on the 16th. Is that right, michael.

B

uh I think so don't quote me on that I'll! Look it up right now, as you're as you're, going on yeah.

C

That's uh that's gonna be our first four day into this, uh so I can. I can just pull up the link and post it on the chat. Oh it's just after this, but yeah that's gonna be our first foray, but until.

A

C

It's just been slack and github.

A

Okay and and so for the most part, it's it's stack, rocks engineers working on this.

C

Yeah we've received a few contributions from users, but uh we are, uh you know, and we are most of the contributions have been internal so far, and you know the uh pr like approvals and merging is currently just stuck rocks engineers right now,.

A

Well, it seems um I was talking with michael a little bit before everybody got talking today and, and we hit the record button about how this seems like a nice complementary 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 um how this relates maybe to operators, because we talk a lot about using operators versus helm, charts and yaml files.

A

There is: is there any work going on vishwa around the operator framework or examining that.

C

uh Not not specifically like we haven't, uh we haven't done uh anything specific to operators. Here uh we um again like since we're analyzing the yaml files to some degree. You know uh if you, if you're able to render the operator into a yaml file or into like its final yaml files like the tool, will work um but yeah. The things that we are uh we focused on, at least at the beginning, have been a better support for hand, charts so with hand charts we.

C

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 hand chart we just automatically uh like render the yamls or the templates and run our checks on them. And another thing we've heard requests for is customize as well, which some people use to manage their configs, but yeah. That's a good suggestion and something for us to look into.

A

Yeah it'll be interesting to see how that works. um 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. No, no! No. If you want to um share that list with them and um walk through that a little bit, I have to unmute you still there.

A

If not- and you probably got that other question covered with a vs code um in your roadmap talk and the other question I think was um around comparing um what you're doing with cubehunter with what goes on in in oppa the open policy agent. So can you talk a little bit about that.

C

Yeah, uh so that's that's a really good question and it's something um you know we we've thought about as well. uh I think uh we we um concluded that, like we ended up building this because we found that uh for us internally, so this actually came out of like internal pain points that we had uh that's.

C

That was like the the initial you know, like spark of us building this and then that later you know, we decided that this could be something the open source, but uh with uh oppa and conf test like you can achieve many of the same results, but we uh we found that uh this.

C

What we're building here is more focused on kubernetes, and that's that allows us to do um that allows us to do some things which are more kubernetes natural, like for example, the way we ignore uh 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 uh and we're just like. If you see a ham chart, we just render it like.

C

Our tool is uh more kubernetes aware, so I think that kubernetes awareness is one big thing that we felt that we could do or in a custom tool, and the other thing is.

C

We also are kind of opinionated about certain defaults text that you know we wanted to enforce internally, and we figured that it would be nice to have those like built in to the tool so that, if someone downloads it, they don't need to uh with with conf test and oppa uh you there are like rule sets available, but we wanted to make it something where, like we also kind of guide users towards saying like these, are the tools that we think should be enabled by default and they're actually built right into the binary.

C

So those are the a couple of reasons we decided to build something uh something different and uh we do. uh I do still think that the oppa language is very powerful, much more powerful than you know. uh The the kind of language we've built with that comes complexity, but we're also thinking of a ways to ways to make our um base to like use the oppa or language in our uh policy configuration.

C

So, like I mentioned the roadmap, I think there are ways to make more flexible uh policies and one of the ways we would 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 coop lintel, but they also get the convenience of you know all our other uh specific features so hope that answers the question it.

A

Answered mine, I hope it did for everybody in the chat um as well and noelle. No, I think you've got your speaker fixed your microphone.

D

A

D

You hear me enough.

A

I can hear you now there you go yeah.

D

Perfect, so I've 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 are up or even small operations teams that have a large number of third-party either vendor applications are 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.

D

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're seeing things around. um You know when you you're working service mesh is mtls enabled on on 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 um uh kind of set up kind of uh standards that have to be enforced?

D

Did you know I mean for to get the application out there so kind of? If you, if you think of like things like um sonar cube for code, this would be the equivalent for for uh kubernetes or openshift resources. You know, that's that's the kind of stuff we've seen so far.

B

Yeah, this is a very thorough list, too, of of policies. um Yeah and and a lot of these checks are actually implemented in cube linter, and the other thing too, is obviously stack rocks is a more complete.

B

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.

C

B

It's uh it, I don't know if that's like a subtle of me, just saying, hey, like stack, rocks, basically does a lot of the stuff.

D

B

um 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 in a consulting role it 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.

B

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 off the cluster, where 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 that this is really cool uh repo. Thanks for sharing this.

C

Yeah, I second that uh noelle, it's uh really useful and we're definitely gonna be looking at that to steal ideas for kublin, though so, thanks for joining.

B

Given us issues and and giving us ideas, what is this? Oh well, you want to come. Join the team.

A

It sounds like a game plan here. This is great. It also sounds. You talk michael a little bit about um having some best practices, config files as well, so setting up sort of recipes and cookbooks for people um to to use as best practices in their own organizations- and I think maybe some of what noel is is listing here- are our best practices.

A

um Things for you know for different platforms that we're we're deploying to so it's actually, some really cool work to go through and collaborate with you guys on so yeah.

B

This is awesome.

A

Yeah we're almost to the end of the hour. um I'm not seeing any more questions in here I'll ask the one out there um cube linter. um Is there any plans for sandboxing it into cncf what you know, what are the the next steps for you guys as a as a project.

C

Yeah we uh we actually don't have um a great answer to our long-term plans, just because we have just been focused on the short and medium term.

C

So far, uh I think we've kind of been focused on just uh the project is only uh 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 uh improvements to it, uh and uh I think you know when we released it, we didn't know what to expect whether, like nobody would care or whether, uh like people, would use it and we've been happy. It's exceeded.

C

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 um again. This is something we don't have a ton of experience with at stackdogs, because this is our biggest open source uh project, and so I think this is something we need to figure out but yeah. To answer your question we haven't, uh given that a lot of thought so far to be honest,.

A

Well, it looks like from the interest in it today and um the work that you've done um 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 uh more on this.

A

So take care everybody, and I will post this video and the slides up shortly um to the youtube channel um on openshift. So yeah, thanks and along with um noel's list of um suggestions there. So.

B

Awesome, thank you so much for having us. It was yeah thanks. So.

C

Much for having us diane, it was great thanks for listening everybody and for your engagements and your.

A

A