GitLab Protect Stage, 20 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Monthly Protect/Compliance PM/UX Sync - October 2021

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, austin, I think you've got the first couple items here.

B

Yeah sure do- and I was working on pulling out my figma page as well as I don't have gdk running right now. um So the first question I had was around the configuration page that is under security and compliance, so I saw that that had kind of released earlier this summer.

B

The compliance tab is a bit misleading at the moment, which I think we kind of already know, but like the description for it says the same thing as security and testing so got to go back and do some revisions there. I was just curious to sam white.

B

I guess, if you had heard anything from camilla or maybe from annabelle or andy around, how that configuration page has been going for security and testing like if there's a direction of more content, you're looking to put there it's to help us inform what might be most meaningful for compliance.

A

That's a good question. I think it's becca that's been driving that most out of everyone. um I have not heard any feedback on that page at all myself, um not that I've been, I haven't, been asking for it either. So maybe that's part of why, but it also hasn't come up on any customer calls or anything.

A

So I don't know what their vision was for the compliance tab either. I'm afraid I'm not very helpful. There.

B

That's okay. I mean, as what kind of happens with the fact that we have the name compliance in our groups. Title um I mean it can sometimes be confusing. What is a group compliance feature and what is maybe more of a compliance feature to users more broadly so licensed compliance is a great example where you don't own that feature, um but it has the word compliance in it. So inherently it feels like it should be tied to compliance.

B

I can do a quick, just walk through what I initially was thinking um as like an iteration from where we're at today.

B

So the first half focuses on security and testing, and perhaps this compliance tab could focus on the compliant management aspect aspect for these given projects, so you can understand if your license compliance is enabled, but are you also taking advantage of the other compliance features that we outline in our docs? Like? Are you using compliance frameworks? Do you have pipeline compliance configured?

B

Are you running any external status checks, ssh key restrictions like I mean this list could be quite long, but maybe we could start with some of our most um valuable compliance features as a way to encourage users to use them if they aren't already using them by creating a single space where they can kind of see that in aggregate, but I'm still not entirely clear on what the intent was for the security testing aspect of it. So maybe that's where I can tag up with and becca better understand how that's going.

A

Yeah, that sounds good. I know what they've got in there kind of varies I've personally, I've always been. That is really the place to store any settings like as opposed to a policy, but if you had a project bubble setting for something you know, that's where I would be inclined to put it, um but yeah becca's becca's. Definitely the best one to talk to you for this page.

B

Yeah, that makes sense- and I think, right now, a lot of compliances features are kind of just interspersed throughout settings, so there are some. I think we could definitely pull in. If we wanted to like a compliance framework is something that we could definitely lift and shift out of settings and put into configuration.

B

um It would probably be a little bit harder to pull out things like inherited memberships, so that sometimes like, maybe redirecting those configurations to the appropriate page would be the most effective, but I'll definitely tag up with her on that.

B

That's good yeah. Thanks for your thoughts on that uh sam courage, you want to add any other questions or thoughts around that.

C

Yeah, I I think my main feedback and what I liked in your mock-ups they're austin, was. It really would help us tell a better story about what is complying to gitlab by putting all of those things together whenever we have to walk users or customers through well, you go to this settings tab to change this, then you go to that one. The story really gets mingled and it almost makes it feel like it's a it's an afterthought when it's definitely not an afterthought.

C

um So I think if there is an opportunity for us to bring a lot of our compliance pieces together, it would really help us talk to that compliance persona. This is the screen you live in primarily, and that makes it very easy for them to understand. Oh, I need to buy a premium or ultimate to get this experience.

B

Right, but also now that I think about it, you probably wouldn't see the configuration page unless you had premium or ultimate.

C

What do you mean like um configuration page from showing or in the settings page.

B

No, I meant like under security and compliance. I don't know if the configuration page shows, if you're just on free.

C

Oh, I see, I guess my point was more of like when imagine you're a person evaluating purchasing, git lab and the person runs through the demo and they have to click through six screens. You're gonna get cognitive overload, you're gonna get distracted by oh well. What's that other thing you don't mean to talk to me about and you might miss the central value point we try and make with the compliance story.

B

Yeah, that makes sense. I also think, even for people that are using ultimate or premium, it would help them understand if they're actually utilizing the features at their disposal, because some of it is. It is like an extension of a feature that you have to know about to know that you're using it so exactly.

C

Cool, actually, that would help us increase uh adoption and other features and other stages, because well I'm not using compliance controls on this other part of git lab, but I am using this one. Let me go explore the one I'm not! uh That might help with some discoverability an interesting thought.

B

Yeah, I think it would probably be a lot of fun end work, which sounds good to me um cool.

B

The next thing I wanted to highlight uh this came up in a uh recent merge request where we were finally appending something to the word: compliance in the navigation because for a while, it just said the word compliance, but once you open it up, it said compliance dashboard to be a better representation of what it is, we're going to call it the compliance report, but tech writing, guided us and saying it should be just a uncapitalized report.

B

So there might be another merge request that comes through for the vulnerability report, not sure if you'd hear anything about that yet same way. I.

A

Had not, I can pass that on actually, as I'm looking through get labs nav, our capitalization is.

B

All over the place, it is, and tech writing is aware of it, and it's just like very slow incremental changes to get the different pages updated appropriately. That's weird.

C

Yeah, I think if we do want to make that change, we should really make a point of doing all of the security compliance menu items together because yeah like just our current state right now that looks goofy.

A

Yeah, that's going to be really odd.

C

I mean that jumped out at me immediately when I pulled that nav item out.

B

Yeah and um all of that I can go sleep and find the uh comment too. If you want me to type writing it.

C

Might be worth talking about it in context of where the capitalization makes sense, maybe that the proper naming is lowercase r in standalone form, but any multi-word menu items are always capital case for every word, just as a presentation approach.

B

You'd have to debate it with tech writing. I think it has to do with the structure of the word itself.

B

So an example like where it should not be capitalized like kubernetes clusters is not supposed to be capitalized, whereas, um like I think, security dashboard is supposed to be capitalized, I think it all has to do just like grammatically what's correct, but I do agree. It just kind of feels a little odd to see a mixture of both well grammar.

C

A

Right now and are now you know most of them, it seems like the majority is capitalized all the words and then their handful. This merge request code review and then the infrastructure tab are the only ones that don't capitalize, but everything else is.

C

Merge requests on the left. Most nav is lowercase. Two, oh yeah, that's true.

A

C

A

Registries is uppercase.

C

And there's also an ampersand instead of amd.

A

Yeah, how odd usage quota success tokens.

A

Okay, um yeah, I mean I can share that back with the team, but it seems like this is a broader navigation problem that we need to rely on. I agree with sam curry, though we should not just change one. Like one item: that's gonna make it stand out like a sore thumb. There we've gotta at least stay consistent within the same menu.

A

Even if we're not consistent in all of gitlab.

A

You have an issue that I can share.

B

Yeah, I will most definitely find the thread that we had around it. um It was between ian um and evan reed, um and then I can link that for you once I find it because I haven't found it just yet.

A

Yeah, thanks for sharing that out I'll pass that on to everyone too um yeah. So my agenda item here was mostly just an fyi. I know we've been talking about this for a long time, but we're actually getting close to starting work on it. We haven't started work yet, but we did put this epic through planning breakdown, which means it's in refinement and the next step after that will be that it's we start working actually implementing it. So right now, all of our security policies are at the group level.

A

We did default that feature flag to on in 14-3, so you probably saw that show up here. This new policies, tab or policies. Page looks like this. One has mostly network policies, but you can also create scan execution. Policies in here looks something like this right now. It's all yaml, we don't have the rule mode yet so it still is a little bit.

A

You know the user. Experience is still under development, but it's there and it works. So the next step is going to be to move all of this up to the group level as well and have those flow down to the project level. So yeah take a look at that epic. Let me know if you have any thoughts or feedback um once we finish that body of work, the next step for us is going to be to filter which projects in the group are affected by a project compliance label.

A

So I know I've kind of shared um this rough idea out with you before, but at a super high level, and this isn't like ux designs, but when you go to create a policy, this is the rules mode that we don't have yet you'll be able to say. I wanted this to apply to all projects where I only want to apply it to projects that have specific compliance framework labels. So this would be a point of integration between our two groups and uh we haven't we're not starting work on that design issue.

A

Yet, but again, this is just kind of a heads up.

A

I don't know what your bandwidth is in the upcoming milestones, but if you have some bandwidth to co-collaborate on that, I'm assuming you might want to show some of this information back uh on the group settings page where you set up the compliance framework label or maybe somewhere else to show which policies are tied to which labels in some way.

A

But that would just be you know again, that's not like an immediate action item. That's just something to think about for upcoming, maybe plan for capacity-wise.

C

One question on that: sam are those group level policies, will those be restricted to just root groups or could they be used in subgroups or any combination of them any.

A

Combination, we're actually implementing it on the new namespace object: workspace namespace, I don't know what they're calling it on the back end. So that way you can implement it once and use it at the workspace group subgroup, group group and project bubble.

A

We won't have ui for managing policies at the workspace because there is no ui for the workspace object yet, but in theory when that is created, we'd be able to use the policies there as well.

C

A

I'm just thinking.

C

Through what we're going to have to do for like if a user creates a policy in subgroup a attaches it to a compliance framework, that compliance framework might also be used in subgroup b, which is a peer of a and so the user might assume that this policy would apply to all projects that the compliance label was applied to which wouldn't be the case, because they're in different subgroups.

C

If that makes sense, yeah.

A

That does um we are trying to help with potential confusion in the way we're going about our mocks for the group level policy management. um So we are planning on creating this new source column. On that policy page and saying you know, the policy applies.

A

You know for the first iteration, it's just going to apply to all the projects in the group, so it's pretty simple, but for the next iteration, when we do have it limited to just projects with a specific compliance framework label, we would notate that here as well and probably even let them click on this or somehow get a list of exactly what those projects are.

A

So hopefully that'll help at least a little bit with the confusion, but I can see where yeah that definitely could get a little bit confusing here again as well like when you create a new policy. We're gonna provide this information icon up top and once we have that filter for the compliance framework. Labels down here um I'll have to play with this a little bit. But we could probably just do some smart inline messaging to make it really clear exactly which projects are going to be affected by the policy.

C

I wonder if it would also make sense for us to explore at some point defining what policy you might want. If there's like a stand-alone policy to any project with the compliance framework, and then it would use the cascading settings framework to set those group settings directly um because.

A

Then you would define it.

C

It would apply to both subgroups that were in there.

A

Yeah, so you could do that at like the group above the subgroup level would solve that problem or in theory, when we have workspace level policies, you could just do a policy at the workspace level that says for any project in any of my groups anywhere.

A

I want you know uh to apply this policy if it has this label, so that would be solved at least eventually um for the short term. You would probably do it at the root. Well, we don't really expose the group very well either, but you could do it in any of your top level groups and it would flow down right.

C

Yeah, I think, that's probably going to be one of the bigger like ux designs, have questions on how we want to approach. This might be a follow-on couple of iterations, but I think that's the feedback we'll get from a lot of the customers, because what a lot of them are doing with the compliance frameworks today is using it to govern multiple different groups potentially and the framework is defined at the root group. But each of those individual subgroups would inherit that from there.

C

So I think that would be to dig into more.

A

Yeah that makes sense um just to show one more mock. This would be like on a project level, so you would be able to see if you go into any given project, you're going to be able to see those all those policies that flow down. So if this was in you know your project or I guess sorry, this is a group anyway, you can see which ones flow down. So this one is inherited from a parent group.

A

These ones are inherited from the workspace and they would actually be read only in this location because um to edit them you would need to go to the respective object to edit it so that you're editing it in the correct place, but yeah, I can definitely see just some very mindful. Ux is going to be needed there to make sure that it's really clear um what you're doing right and where those policies are being applied.

C

Are you still thinking about policies as an additive, only sort of experience or have you thought about any sort of reductive or preventative sort of policy? Since we last talked.

A

um So so far, we have don't have a need for policy reduction. All of the policies that we have today are purely additive. So if one policy requires a scan to run and another policy requires a scan to run, you can just run both scans there's. No, it's not really a strong need to try to deconflict things like if you're, both requiring a fast scan to run with slightly different parameters.

A

You can just run it twice once with parameter set a once with parameter, set b, all right eventually, you know if we do run into that, which we probably will at some point the policy that we're planning on pursuing. There is one where the first of all the most restrictive action will always take precedence.

A

So a policy with a block action or a deny action will take precedence over anything with an allow action and the secondary rule to that. If there's a conflict, that's not resolved with the level of restrictiveness, then the more specific policy will take precedence. So a group level policy would take precedence over a workspace level policy and a project level policy would take precedence over a group one and that allows users to define like a broad organization policy set and then create project level exceptions as needed.

B

Do you anticipate the inverse happening like uh organizations saying we want to set the broad level policy and not let these projects define their own set.

A

So the way we're structuring this, it would be the same individuals responsible for all of that. So it's you know we're following a principle of separation of duties here, so that it's not like there's another group that can go and set a project bubble override. It would be that same group of individuals that would be responsible for the project policies, as is responsible for the workspace policies. So if they don't want to override it, they just don't override it. It's not like they need to prevent someone else from doing that.

B

What, if they don't want to abide by something in their group levels policy, though,.

A

So they would be the ones creating their group level policy, okay and then they can also. If they want to override it, then they can at the project level. Okay, because we're already separating out the policy management from the developers.

A

Anyway, um you know so whether it's the security team or the compliance team, that's managing policy.

A

That's managed, often it's similar to the way you're doing compliance pipelines and that it's managed in a separate project. So those individuals can set their own access controls, their own merge, request, approval workflows, and so it's not like there's, like I said, there's not another team managing project bubble policy that they need to keep from overwriting the workspace policy. It's the same group doing both got it.

B

C

I definitely think it is.

B

C

That'll help reduce a lot of the complexity. um That was one of the things we ran into with compliance pipelines is how do we, let customers define multiple definitions and then disambiguate, and we ultimately just said you can't you get one and you have to disambiguate yourself.

C

I think you sidestep a lot of that with the additive nature. The way policies are today, which is great.

A

Yeah, I mean to be specific, we're injecting a job into the pipeline with a really long name that, for all intents and purposes, is going to be extremely hard to just guess: it's more or less a randomized, big, long string of numbers, and if there already is a job that is created in the gitlab ci.yaml file, then our settings override anything that the developers created for that job.

A

um So in that way, we're able to just run multiple jobs for everything that we need and we take precedence over anything in the gitlab ci.yaml file, but other than that there aren't really conflicts. We don't conflict with our own other policies. We just use. You know another big, long, random string of numbers essentially to create a separate job for each thing that has to run.

A

Cool um all right.

C

Another question just kind of because I was playing with it earlier. I think I saw dast and secret detection or what scan execution policies are there today? What does your roadmap look like for other scanner types.

A

We are going to be adding support for sas next uh that we're gonna start working on it. This milestone it will we're not committed to delivering it in 14.5, so it'll probably be delivered in 14 6, and we're actually doing that before we move things to the group level, so um that'll happen first and then we're going to take a pause on adding new scanner types and instead move it to the group level.

A

And after that we can revisit adding more scanners. If we need to.

C

Got it okay, yeah now I think, moving sas is a really smart idea. Since we have so much adoption, more people will use the feature. uh If sas does that.

A

Yeah, absolutely it doesn't have full like customization by default, we're just going to run sas with the same settings that are used for the default, auto devops template, so they won't have the ability to customize any of their sas variables other than maybe one. I can't remember which one I think we're letting them customize one.

A

So it does have some limitations to it like if you're, using a language that we require the compiled binary to scan, which isn't a lot of languages. But there are some that we require that. Then you can't really use this. You know there are some like caveats like that. That will have to add configuration settings more in the future, but we should be able to cover at least the majority of sas use cases with that iteration.

A

C

I think we're at time, so it was great uh great job with y'all yeah. I.

B

Did I did find a tech writing comment as well, which I uh highlighted in docs awesome in case you're curious? It's because it's not a proper noun. Okay.

A

I'll uh I'll share that out and we'll weigh in on that as well. Yeah sounds good. Have a good one.