StackRox Community, 9 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: StackRox Community Meeting #5 - 2022-08-09

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

All right, hi, everyone welcome to the august version of the stack rocks community meeting, I'm a mike foster community chair- and I have the co-chair here with me, matthias, coming in from germany he's about to take vacation. So we wanted to keep this one short and sweet uh with some quick announcements.

A

Matthias, you want to kick it off. Yeah.

B

Sure so most people might be wondering because we're even fewer people than usual. That's because of two things: one uh acs engineering, so the folks that develop stack rocks have a hackathon running right now, so most of our engineers are actually there and I I spent the day hacking away as well so yeah and also it's holiday season. So that means a lot of people are on their personal time off which I I will join them shortly.

B

But that also means please be a little bit more patient with prs and issues it might take just a day or two longer for people to react.

A

Yeah I'll be checking when I can. Typically, we tend to do a triage at the beginning of every week, just to make sure that everything nothing's missed. But if something is urgent, you can always message us in the slack channel I'll be around I'm in north america. So I don't get quite as much vacation as uh my european counterparts, um but yeah just uh we'll see in the chat for anything uh urgent and uh last month we announced uh 3.71 release. We talked about the dashboard, so three, that's everyone is ga recommend the update.

A

It's all there. It's been pushed still actively looking for feedback, uh maybe throw we will come up with a little competition c for some feedback for some stock rocks gear, but uh yeah anything in the chat would be awesome in slack or an email would be great, and I see that boaz who couldn't make it also put in the in the community meeting documents, there's a call for devops engineers, cloud, architects and application developers to implement our development project around kubernetes network policy.

A

So the project's going to aim to help introduce netpool to ship left during the dev life cycle by automating tasks with the help of machine generated network policies mathias. Do you want to expand on this a little bit yeah? That's that's a very wordy sentence and hey claude.

A

B

Is- and I can maybe provide a little bit more insight from engineering because I'm actually the lead developer for that project, fun fact. So what we're doing is currently we. uh We have the feeling that, or we actually know, that a lot of people are um kind of tip-toeing around network policies, because network policies are kind of a complex thing, they're not easy to use. They are, however, very powerful and they have a lot of advantages uh as opposed to, for example, third-party products. So we want people to we want innate.

B

We want to enable people to act, make better use of network policies and one of the ways to do that is actually doing static analysis of your workloads. So the idea is, we have we introduced a new command to roxcuttle our cli tool of the whole platform, and that command can go basically goes into your workload.

B

Reads all the yamls and then tries to recommend you a set of network policies as a starting point. So that's kind of cool because we aim to to enable people earlier in the process to do that. So the shift left part of this, which is usually who does network policies. Usually it's like operations, team firewall people uh netsec. So what we want to do is basically hey what about?

B

How about developers also giving tools developers in their hands to actually do that, because they usually know their workloads better than the ops people do, because they actually develop their workloads themselves. So.

A

Because and to if I can expand on that, because tip of the typical workflow was you get into the user interface? And you see the network traffic, you see the baselines and then you get recommended network policies, but that's a little late. Your developers have already pushed into maybe dev and testing.

A

What you really want to do is make sure that they can run this check early on, so that the network policy ships with the application into dev into testing and then that way, your security or your operation scene, that's working in the application can do more verification checks that the firewalls are set up properly, instead of going back and recommending something in the first place. Right and we see, boaz is just joining as we are detailing his uh his addition to today's meeting um boys. It's good timing.

A

We just uh we were just talking about netpoll and specifically the shift left policies and network policies, uh anything that you specifically wanted to get as a call out for a call to action. We don't need to be redundant and explain it one more time, but.

C

Yeah, so I'm assuming I don't know how much uh matthias has shared so far pretty much everything shared everything. This is we we're this is new territory. We want to understand how people would like to solve this challenge. We know it's a problem to share the it's a shared responsibility so who owns it? What does the developer want to do so?

C

On one hand, developers seem to be the in the right place to know what they want from the application, but they don't necessarily they're, not necessarily positioned in the right place in the path to actually author that network policy.

C

So it's it's a chicken and egg kind of situation there and we're really interested in hearing people how they want to solve it like if you're a developer or, if you're, a devops, engineer cloud architect. However, you call it engage with us. We think this that we we have. We have the direction to really help the industry solve this problem, because as soon as you, you introduce machine generated uh recommendations, at least initially the recommendation, the the better technology gets the less human effort. I mean this problem becomes much easier to address.

A

Awesome thanks boaz as a someone with a little less, let's say in the the conversation for me as a as part of a ci cd process. I think that's awesome like if a developer could push just their basic development yaml and then, as part of a check, it goes and says: hey. I recommend you checking this into your github repository with it. I think that would be pretty cool. uh But yes, again, boaz in the slack channel is probably the best place to find you or community at stackrocks.com for email.

C

Yeah find networks or find me equally we're we're both uh teaming up on all of this. All of this effort.

B

Lastly, generally community folks, so if you, if you could completely dream up your your dream tool, please let us know how you would like the experience to be what you would like us to do, because we have some ideas: we're already actively working on the first uh on the first draft. Basically or that's it's not a draft, but we're already working on this, but we're absolutely open for feedback.

B

So if you folks have a great idea feel free to share with us, because we're really interested in because we're trying to help you so basically let us know how we can best help you sweet.

A

uh And speaking of us helping you we're hoping that uh we can, you can help us in a way because we do have the hacktober coming up so we're looking for recommendations. We have things like an operator. That's still, it needs to be in the works for the kubernetes specific built for stack, rocks native arm builds, documentation guides how to um sort of in the brainstorming phase. But if there's something specific you're looking to work on we'd love to hear from you cheers, did I miss anything there.

B

Absolutely not so for me, it's important to to let to also talk about this because contributions don't necessarily mean to code. So if you don't want to code, if you feel like you can't contribute in a meaningful way in code, that's totally fine, because most of this project isn't actually code. It's documentation, it's how to's it's it's! Basically even feedback is, is worth their weight in gold for us, because we need to know what happens to you, how the reality is for you or what problems you encounter.

B

So let us know- and if you feel like, we should maybe build a guide together or write some how-to's together or you want to write how-tos. Please feel free to share them with us. We're more than happy to accept all of this.

A

Awesome and for our, I guess, last tip of the day, we just want to open the floor to anybody who's on the call anything that you want to bring up any uh discussion points things you want to see.

A

We have a question. My question is the new network policy scanning tool will only scan yaml form from the dev machine, not any node right.

A

B

So the network generate so this is the we actually introduced a new sub command to roxcuttle, which is generate netpol, which will recommend you network policies, and the idea is, you will provided a folder and it will read all the yaml files in your folder and statically and analyze them, so we're not reading from the node. What we do from the node is what you see in the network right, so you can.

B

If you deploy a new workload, usually after a short time of running of that workload running, we will recommend you run time, uh runtime network or we will. We will actually show you what your workload did and um and basically recommend you a set of network policies that you could create from that.

B

C

B

C

Is is fundamentally right; this is this is what what we do now. We scan your local environment.

D

Thank you. Can you hear me.

C

Yeah we can hear you now.

D

Yeah, uh so I have a few other questions that are related to this, and uh I mean: can I just throw them out here sure.

A

D

A

D

The first one is related to um again closing the the loop if you will on um scan. So one of the things that my customers have been bringing up to me is basically the wrong scans right of maybe the security team we're on the scan and they tell them.

D

You have things to be uh fixed or remediated right, but then, um once the thing are remediated, which most of the time are usually done already, because usually when you uh provide these to see our hsas, which technically means that how they address them, even though they might not have uh addressed them in container yet right, but once they do that they want to know how do they get that credit without necessarily having to perform new scans? So say they went in and it was a container and they got the newer version of contender.

D

So it was a, uh I don't know: ubi based container say a dev uh namespace, and so they got you know a security vulnerability and then they were told to fix it and they went and went through the process of bringing the new container for red hat and then they basically redeployed the application.

D

uh At that point um they still have that thing that went into uh reported into the uh sim tool said that they went complying right and now they're back compliant, but until they did another scan. There's no way to uh you know match those two state states basically and they're wondering how do they effectively do that, especially when you have a larger cluster for tons of tenants.

D

C

Wait so what what? What is the where? Where is the pain in the current process, waiting for the next scan? Why is that painful? Well, I think, because.

D

They are afraid so again coming. I should probably provide about background these customers mostly run disconnected right, so they're not always sure that performing another scan would actually give them clear. They are afraid that if they did another scan, maybe something else would come up which might not even be related to the issue right at the end, so they don't want to keep whacking them all so to speak, so they basically want to make sure that okay, this is an issue that you raised to us.

D

uh This issue has been addressed and we just want to mark it as address but they're afraid. If we do another scan, maybe something else will bubble up, because maybe the version of the database is not in line and things like that. So that's why they kind of, I was afraid of doing.

A

If I can uh jump in here, I think there's are you talking about doing a scan through the user interface and scanning like multiple clusters for all of your container information at one time.

D

Yeah, that's what it usually is.

A

Really in terms of how I've seen it used effectively for reporting and for this information I would say that if you find a container that has a severe vulnerability, you want to kind of move left into the build process and use that rock ctl to scan only that container in the build process or at the developer level, because when you scan it and then they go and fix it, and you scan it again, you're only scanning that one container and the readouts that you'll get from the policy violation the cve information.

A

That should be enough that you can just you, know, copy to a text file and send out and make sure like okay, yeah. Okay, we fixed this eventually, when you do a larger scan that will show up right. um But if you want to I kind of see the issue like if you're scanning a multi, multiple clusters, you get too much information if you're scanning a single container. Maybe that's too small!

A

Is that the issue, but I I just recommend that you would scan with the roc ctl um and give it to the developer for reporting so that they don't have to go through the ui. Every time.

D

Okay, so that addressed the tenant one, what if it was the platform itself right, so they not only scan um the worker load, which are the tenant worker load but they're also scanning their own platform. So, basically, you know the platform. Our credit openshift is created on those networks and so openshift needs to be kept in tip-top shape. So every time something comes out, it gets openshift, uh they have to remediate, which is larger, so we always scan anything that is officially specific and then scan the tenant. Stop uh separate of that.

A

Yeah, there's there's a whole conversation. Actually that's a good point. There's a couple of rfes and things that were changing because the way that we mix vulnerability data and configuration in kubernetes and openshift might it leads to sort of a perception of risk right, and so, if openshift has an operator and it comes in and installs something on the node technically, that operator has privileged access, so it kind of gets elevated in terms of a risk assessment right realistically, that operator was there and now it's not doing anything.

A

The container's been null and void for forever, but it still shows up on the scan right now we tend to approach it as it's way better to have full visibility into these security issues so that you understand what openshift is doing underneath the hood. I understand customers, don't necessarily like that.

A

You can create policies to ignore these specific operators. If you would like, I know, there's some feature: requests in the future to sort of have different triaging for those vulnerabilities. That being said, typically most vulnerability, issues that come in at what would you say, high or critical are the ones you want to focus on. I understand some security teams. They see a medium or low and they're like. Oh, we have to get everything in tip-top shape.

A

Realistically, that's um you're gonna be banging your head against the wall if you're trying to get rid of all the vulnerabilities in all of your clusters all the time right. So I think, there's I don't know your specific use case, but there definitely is a conversation there about what is important and what isn't um and if acs and stack rocks isn't showcasing that well enough. I think that that's a bigger conversation that yeah that deserves a write-up. To be honest right.

A

um I I yeah if you want to chat off um after the meeting or something and type it up and then have a discussion, I'm more than happy to, because that's a pretty deep use case.

B

Do you do? Are you in the slack claude.

B

Are you in the cncf slack um yeah.

D

I'm this I mean this next channel yeah yeah yeah,.

B

Okay, yeah, so because I would be very interested to to also be included in that conversation, because it also sounded to me like uh something like partial rescans would be nice to have in the ui right so that you can just trigger a rescan for this specific container or issue you're. Looking at right now, correct.

D

Yeah, yeah and and that's the thing that we've been trying to bang our head against, like I mean uh when we it to this platform, uh when they do actually the security team, uh they scan it, and then I get this this list of uh sometimes a cvs, sometimes uh rhs and I'm told well, you need to go, get us the remediation. I have a playbook that called the apis and provided the csv is for them, but then once they load that into the sim, then they come back and they're like well.

D

We don't want to rescan it because we've done it before. I just had it last weekend where they're like we can't we scan it, they want a new scan, but we can't do it because we know from his face that if we do it we're gonna get more stuff. So these guys are not gonna grant us the past status that we need, and so so that's why I'm like okay. So how do we kind of solve this problem where they're, not so afraid of we're scanning?

D

Because, ultimately, we just we fixed it right, but you know they're afraid that if we do it again, it's going to trigger something that said they don't want to open that kind of wall. Then.

A

Yeah, it's a bad pattern. It's a bad habit that we want to avoid so um yeah. Okay, we understand partial scanning uh matthias. I think that's uh that's one that we should probably bring up internally right.

B

Oh definitely, I've already made note of that. So, let's uh I I would still like to have that conversation in the slack, maybe and then just collect some more details and information.

B

But it's a it's a great use case and I think it's a very valid use case that we should at least talk to talk to our pms and and our our uh our planning department about.

C

That that said, the um the direction mike was going with uh with rox cuddle. I mean that that is the right direction. uh Developers are, don't typically go to the ui. Are you familiar with rock's cuddle club yeah.

D

I'm fabulous myself but again, uh and this is something we want to institute in this organization. This is a large. I mean thousands of people weren't running using these clusters right, and so we we've been talking about that. I mean I. I was talking to you all about the rfe that you have with uh the credentials because they wanted the developers or at least the teams, the tenants team right, the name spaces to be able to go to the ui to see their vulnerability.

D

Because again you have ato, you have multiple layer of ato and so yeah one uh app dev team. That has an ato that says the app has passed, but now they have done these and they have dev teams say well, we don't go to the ui, so we don't know what was you know against us, so they wouldn't be able to see it. And then these guys are.

B

D

Well, openshift the permission doesn't carry into ses and so there's a lot of mess in there. But you.

C

Guys, but that's actually that's how most customers operate most of people don't want to go to dui, but that's exactly why rocks cuddle is the right direction.

D

Yeah I mean I, I do agree with you that that's I mean again, those are things that you you have to put in place again. You have yeah.

A

D

The cicd tooling, and all of that so that it's enforced right actively enforced.

C

Even manual so it doesn't have to be automated. I think the point that mike is saying is that developers and devops should get comfortable and working on rocks, cuddle, yeah.

A

Because they could definitely rescan.

C

Just a single component, a single image, single deployment.

A

Yeah and the only way that you're really truly going to let's say you have a get into a massive cluster and you have you know a thousand policy violations. The only way, you're realistically going to start shrinking. That number over time is through the automation earlier in the build process, so that you know hey, you do need to upgrade your image. You can't allow this thing to be.

A

You know nine months old right and so then developers will have to start changing their cadence and how they work earlier in the build process, and that will slowly bring down the uh the different vulnerabilities and policy violations in the cluster so that every time they do rescan it they're, not. You know going from a thousand to nine hundred back to a thousand to nine hundred back to a thousand to nine hundred right, um because then you're not really seeing any progress. So it's it's just like um I don't know it's like it's almost.

A

I don't wanna make the equivalence, but it's like babysitting and putting up specific rails to say, hey as a kid. You know you can only stay in this room like slowly. Just putting up rails and just guiding them to to the right spot, um but yeah, I think it's a great use case. I would love to finish the conversation in the slack chat honestly um and and on it. Whenever you talk about customer feedback or you know, they're they're banging their heads against something, I think that's that's great to know.

A

Can we fix something to slightly get rid of this anti-pattern, because we definitely do not want people to be ignoring uh security information for the sake of not hitting a rescan? I think that's, that's, not a that's not where we want to be right.

D

Yeah, definitely that I do agree with you with all those suggestions I'll pass that one along to them, especially with even though they have to developer, have to do it again. uh Developer. Doesn't his machine, that's good, but again it doesn't pass monster right. I mean I'm a developer. I did I say: well I just rescanned it it's good. The security guy over there he's got so he is trusting his tool and that's the problem.

D

That's the disconnect right now, but at least if the developer does- and this is where he doesn't have to go to the ui which reduce the amount of people needing to have access to the ui. So I agree with that. We'll pass that along to them and start adding that to the tool set so that they can, as part of the build process to start doing that locally.

D

But still, though, we need to be able to do this uh at a more automated level so that the security first also can see it and see that okay, now it's being mitigated without needing a new scan or you know, shut up.

A

Yeah for sure, thank you. No thanks for the conversation that was great um any other comments. Question concerns boaz david.

A

No nothing here, awesome. uh A last part of our wrap up is our monthly rockstar. This week's this month's monthly rockstar is uh dane. Kentner uh he's been pretty active honestly since we've been open source. I I believe he was from uh a previous customer and it's using open source stackrock, so super happy that he is always active in the chat and helping us debug through some some issues. So shout out to dane and I'll be messaging you shortly uh matthias.

A

Do you want to wrap it up for us before we before you head off to vacation matias is going to be up for the next month, so congrats.

B

Yeah, so I'm really looking forward to that and also that that also means folks, uh please be a little bit more patient with us. But besides that, I hope everyone has a great month, uh hopefully see you next month, and then we shall talk a little bit more about hackathon, and ideally I will have prepared already the open issues that hopefully people can jump to if they want to. So I guess that's it from my side. Folks um have a great day was a pleasure to have you here. Awesome take care everyone.

C