GitLab CI/CD UX Team, 30 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX: RBAC permissions mapping exercise - CI/CD

Description

Daniel Mora from the Authentication and Authorization group syncs with the CI/CD UX designers to evaluate the permissions mapping effort done so far and investigate next steps to progress the RBAC project.

A

Cool so thanks, everyone for joining I wanted to get in touch with all of y'all, because I am working on a project with the permissions. Some of you may have already seen the work uh that I've been doing a couple of you all have already provided feedback. So that's great.

A

um Let's start with this real quick.

A

So just a brief overview in case you're not familiar, um I've been working with uh Amelia and Andy on um redoing, the entire permissions architecture in the platform based off of the idea that we're going to make um customizable permissions and so Amelia had gone through, and uh the first round of organizing the permissions based off of what they have here in our documentation uh on this table here.

A

So you know analytics would be grouped as one and then we would try and find out where his clusters be gone to what is a container industry Etc, so that was the first pass I did um after we had started. Looking at some of this, um we under we started seeing a problem where, as an example where, if I were to look at a individual permission called view, project code and I was to disable this permission.

A

If we were not looking at what it links to, we just look at this table was like well individually, doesn't do anything, but, logically, in the platform, it would turn off all of these other permissions without noticing.

A

So what I've done is I've gone through and mapped all of the permissions to try and see if I could find these sorts of mappings and tied to this issue. Specifically, the devs are looking at consolidating this permission to view Pipeline and view pipeline details so that, instead of it being two permissions, it's just one um kind of like consolidating line items here in this table or the same thing here.

A

The idea is that, if we're going to move forward with um having a prototype where an admin can go and toggle individual features, if we try and minimize this complexity, um that can help on the back end with the problem that they describe here, that um they would have uh there wouldn't be a need for overlapping or redundant permission. So, in the case of here they have the same access level.

A

um We wouldn't be um less confusion here and then uh it would make things easier to undo or to make changes within the the code base, without being so catastrophic towards like if you allow something that they shouldn't have access to, they wouldn't necessarily cause any sort of negative impact in the in that sort of permission. If you were to enable that permission right, so the reason I need you all to to sync with me today is to kind of go over.

A

This um uh vitika and Gina have already kind of looked at this a bit um and I think it's more or less okay, but I just wanted to kind of go through um as part of this work that I'm doing here, where I go through the entire um permissions architecture and meet with every team.

A

That kind of has Insider impact with this to make sure that I'm thinking of everything in this model and then also see, if there's opportunities to merge or group things that don't necessarily need to exist individually uh and so with that I will open the discussion for anyone who wants to kind of jump in and provide feedback.

B

uh uh The first question from me Daniel is like what is the um like basis of consolidating like? Are you thinking of in terms of page access, or is it dissociated? The the primary uh permission is dissociated from the page access and something an entity of its own.

A

So the idea would be specifically in this case, where view pipeline page and view pipeline Details page. The question presents itself: why are these separate? What is the use case or the job to be done to have them individual, independent permissions, and so, if there isn't a real, realistic or definitive purpose for them being separate, then can we merge those?

A

The benefit is that it reduces the code, uh the amount of code that we have and reduces things that are it's touching, um so it kind of improves the security in that instead of having to watch or monitor two code code points, you actually are just looking at one and then that sort of logic would apply to the whole uh project that I'm working on right, so minimizing the code base or reducing it in terms of complexity, as well as what sort of improvement that'll present on the front end where an admin doesn't necessarily have to toggle.

A

Two of these features you can just toggle one instead of and excuse me instead of two and then make it simpler for them. Reducing the UI.

B

Got it so one thing that I just noticed in the link that I just shared uh it's just your list of permissions which are specific to pipelines on the dots and while looking at this table. If you see the we have separated out view pipeline, detail, speed view pipeline page and view pipeline tab in Mr and when I kind of cross checked that with the documentation that I have in my personal Excel sheet. The only difference that I see between um accessing the pipeline list view versus the pipeline.

B

Tab in merge request is that guests cannot access uh the pipelines in a merge request.

B

So that's something that I think we should also cross check with the team if there is a possibility to consolidate that with these two permissions that you just talked about, unless there is a very compelling case of not allowing guests to visit that particular job in a mode request, but at the same time be able to look at the pipeline list. View.

A

Well so one thing I guess I should probably clarify- is that this change doesn't necessarily have any reflection on guest reporter developer maintainer owner. The idea being is that as an admin, I can then customize all of these to offer those individual permissions. So if a guest only had access to one particular permission, I could then enable that they would no longer be a guest, so any sort of restriction that you're seeing by a non-member or a guest not having access to that doesn't necessarily play into this particular problem.

A

I, don't think, okay, apart from what do they have currently and can I enable or disable that um the idea being that an admin would then give custom feature custom access to something the impetus for the project is our permissions are either too permissive or too restrictive. So if somebody can come in here and say, I want a guest role but I'm going to also give them permission to run a pipeline and then disable all the other things that could be possible.

A

um But we're looking more so is that um any sort of problems that might arise by making those changes by if I do allow that does any sort of security concern arise or um again going back to the idea of merging stuff. If I merge a particular permission, does that have impact elsewhere.

B

Right in that case, I think it definitely makes a lot of sense to kind of treat the pipeline tab in merge request the same way as we treat list view. The only thing uh that I don't think I have the I have complete knowledge to comment on is uh how that plays with the access to merge request page because, eventually, like the same pipelines, are also going to appear on the python list view.

B

So if somebody is able to view that, then this should also be able to view this is just presenting the pipeline list to you in a context. In the context of a particular merge request,.

A

Yeah I guess that's also something where I was looking for. Your knowledge is that so, as it's grouped so far, we're just looking at this CI CD screen, but it doesn't necessarily just stop there right. So it touches merger quests, and you know, parts of the repo right. So are there connections there that I'm not linking correctly because they're in these little boxes right? Should this be a more um connected prototype or not prototype but um connected um mapping? Here.

B

B

So um I'm, just thinking of this hypothetical scenario that.

B

Is there a possibility that I might, as a user, be given access to view pipelines, but not take part in merge requests.

A

That's that's possible. That's the the whole idea of that. If an admin wanted to create that custom role or custom policy, then we would offer that ability.

B

And how would that play out if I still have access to like if, if I can still view, all the pipelines.

C

B

That not through that particular location right.

A

And that's exactly where I'm like thinking, okay, what sort of problems does that create like, like the one I used here of view? Project code is like well I turn that off, but then everything else below that should turn off as well.

B

C

So if you don't have access to merge requests, you shouldn't have no.

B

C

Shouldn't yeah, you shouldn't have view pipelines to have in Mrs Right that would just automatically be shut off because.

A

C

A

Kind of what I'm wondering is that if you would be able to see, uh merge requests or if you don't have merge requests, you wouldn't be able to see Pipelines.

C

B

I, don't think so, I think the whole Magic. If, if I'm not allowed to look at merge requests, uh then of course I cannot access that page and um the tab is anyway not going to be available to me.

C

But I don't think that impacts pipeline's Page by itself right. That would be a separate permission. Yeah.

B

It's separate, that's what so I don't understand.

C

If you, if you can't access pipelines, though, can you access jobs, because I was wondering what the difference between the pipelines list page and the details pages and I'm wondering if it's because the details shows the jobs within a pipeline and sometimes um specific users can't see the jobs because they contain whatever.

B

Sensitive data yeah. That's the question that we should ask back an engineer that if, if there's a let's say, if there's a disaster, assessed like compliance related jobs that are running as a part of pipeline, are they inheriting the same access as the parent pipeline, or can that be controlled?.

A

So my assumption was like you'd look here at the pipelines and then look at the pipeline detail.

A

Or is that no? This.

B

Is this is the comment page.

A

Commit yeah yeah, of course,.

A

Another thing is that, where is the detail shown? Would that be in the Mr.

B

This is the D2. Oh.

A

Here, oh yeah, okay, yeah, so.

C

This is yeah and the list you can see like there's a list of jobs down there too, like in its own tab that and then you could like view jobs but uh technically I guess you could do that from the pipeline mini the little mini graph as well. Yes, I.

A

C

B

C

B

To the list view pipeline.

B

Yeah, um here's the.

B

So it's kind of tight if you're able to view pipelines and view the pipeline details, I mean just few pipelines. You can also view the jobs and job details.

A

C

A

So this sort of all these screens then need to be looked at as a linked linking from all of this right. It's not just independent time back to here. Okay, right.

A

uh And that's kind of what I'm also curious is, if you were to disable that what does it look like from the UI that basically just disappears these? Can these navigation items I? Guess that's how we are handling thing right now, I mean with just basic permissions right. If you just don't have access, nothing will appear right. This tab would go away yeah.

A

This theoretically would go away.

B

I, don't think that goes away that ever goes away.

B

A

B

Who has access to the merge request? uh Has access to the pipeline widget.

B

There is one restriction that they cannot run a pipeline if the pipeline fails, but I think recently we made a change that uh if a pipeline fails, uh developers should have access to the Run pipeline button, which is inside the pipelines, tab.

A

You mean, let's see where's, the Bible is here yeah.

B

A

That's the Run.

B

Pipeline button, oh.

C

This one at the top yeah.

B

Oh, that's oddly placed okay um that uh was not available, I think to non-maintainers, if I'm not wrong, I'll check, um and so if, if a pipeline fails for a merge request, any other developer working with that, you probably could not run the pipeline manually.

A

Okay, well I mean so right now. I am not a maintainer on the git lab project. I.

B

Don't think- and you can see the button.

A

Yeah and I could probably push it, but I don't want to.

C

That's okay, yeah.

A

I don't know if.

B

That you're saying that.

A

Should not be that way.

B

It uh we recently made it available for all I I. Think I'll find the issue um anyway. What I'm thinking is like, let's say, if I don't have access to this merge request? Would these pipelines not be visible to me on the pipeline list view as well, because they are there as well.

A

B

That doesn't happen today. I think.

A

Right, so that's where I'm curious is that what amount of data would be visual so, like you wouldn't see the Mr.

A

But for some reason you could see you could see uh the pipelines if for some reason they were turned on, but you just couldn't see this content and maybe the changes yeah and the commits.

C

What what? How would that information help like what? What would someone use that just that commits pipelines and changes for an mr4 I'm, just wondering if it even makes sense to just show those without the actual Mr description and everything so.

A

I think, let me jump in real, quick, because I wanted to make sure I'm understanding. I think this might just be a bad example where an admin would disable that or enable that to allow that sort of flexibility or to to prevent seeing something here.

A

um I would look at it more holistically across the platform, as like saying is there something that would negatively impact it?

A

um The example we're using I think is is a fair example, but it might be like an outlier case right. I think the more relevant example might be. um I, don't want uh an external contributor to see code, but they can look at the the merger, Quest and um where's. The merge request real quick.

A

It's a thing of it like from a matter of security perspective where I was like. Okay, I want a contributor, but I don't want them. Looking at something potentially problematic right.

B

A

So disabling pipeline might not be an example that would be valid, um but it is the one that they're working on right. Where was that issue?

A

I've lost the issue, uh oh here it is where they want to merge these two.

C

A

I think for me that the problem is I'm I'm, more afraid of what happens when they go to something that is actually more likely to be played with, and disabled I think that might be why they're going after this one in particular, because it probably nobody's gonna mess with that right.

A

C

There's no reason to disable.

A

C

A

But this would be these two are available for every level right guest has access to this.

B

A

Yeah, so I think that might have been why they chose is because it's super low impact.

B

B

But uh jobs are acts like permission, for jobs are definitely tied to these. So if somebody has access to view pipeline, they can definitely look at the job, details and job list.

A

So I think what I want to do next is talk with my engineers and ask them: what do they see impact Wise from that outlying example? If somebody did for some reason, disable that permission?

A

What does that look like in this case, because I'm not exactly certain how that works, because, as you described, it won't just be contained to this pipelines page it actually goes all the way back to the merge request and this whole screen.

A

Am I understanding, correct.

B

That's correct so like out of the 12 trigger sources for that uh initiative pipeline come, it is I, think one of them and commit is again related to the changes and uh like for security purpose. If the changes have to be hidden from someone what happens to the pipeline permission.

A

A

C

One other thing to to throw in there: it's not fully live, yet it's only enabled for this project for git lab projects. But if you go to CI CD, we also have artifacts now, and that depends on jobs and Pipelines. So it's like the way that we think I was just saying. If, if you don't have access to a pipeline, you don't have access to the jobs, then you also won't have access to the artifacts.

A

C

There's like a whole cherry, yeah,.

A

So I guess that's something that I need help with over here is: can you uh help and fix this tree with me to make sure that the links look correct from your perspective?

A

uh Yeah so like I think that's my my ask for the team. Is that just double check what I have so far and make new links or break links, as you see um relevant to your group and then also just you know, feel free to note or call out anything that might be weird or problematic, and we can talk about it. Async and, like I, said I'm also going to pass this through with the devs. So they can see um what we're talking about in our concerns.

C

B

C

Runners now that I'm, just looking at this is I never even know. Add ad Runners to namespace is an existing permission.

B

Sorry come again: Gina I.

A

Think so let me.

A

Find it no there's only six links.

B

It says, add specific Runner to project it's listed, yeah, okay,.

C

A

Yeah product will be in namespace.

B

It's limited to owners and maintainers.

C

Yeah, okay, I'm just trying to think of all the things I'm gonna think about it. A little bit more Runners are like the permissions are so complicated, so I'm going to take a closer look into into that.

A

Cool so yeah. This has hopefully been helpful and I hope. um I have explained what I'm trying to do correctly.

A

um I guess if y'all have any other feedback um for the meeting today, I don't want to I, don't want to keep you longer than our schedule.

A

Okay cool so then yeah, like I, said um when you have opportunity. um Please um add some changes here or links that I'm missing. um That you think should belong here, especially like across uh these sorts of features.

A

um I think that's mostly where I'm lacking is where they touch across the platform.

B

There's definitely an overlap with the security and compliance and the create features. I mean that and and also package I guess.

A

Yeah my assumption was, there should be a lot more links, but that's kind of what I was hoping to have these chats with everyone to see which ones I'm missing.

C

A

Awesome well thanks. Everyone I appreciate your time and it was super helpful for me and I'm glad I could catch everyone in the same time, slot I hope I did keep anyone up too late or wake anybody up too early.

C

A

Thanks again good to see you all have.

C