GitLab Customer Success Skills Exchange, 27 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab Group Hierarchy with SAML and SSO

Description

Jefferson Jones, Solutions Architect, provides an overview of GitLab Group Hierarchy with SAML and SSO

A

Hello, everyone and welcome to the customer success skills exchange this week, we'll be talking about group hierarchy with sam'l and SS Oh, our very own Jefferson Jones is here to give us the you know, quick and dirty what we need to know so Debrecen. The stage is yours, awesome.

B

Well, a Solutions Architect nice to meet everyone and thanks for joining there's a lot to cover I'm sure you have many questions, because this is a topic that seems to come around all the time with customers around groups, hierarchies structures, sam'l as ISO and and it doesn't help at all that we have get lab comm with some limitations and it's all posted, what's the differences, so things can get really challenging.

B

But what we want to do is make sure that we're setting correct expectations for the customers, because some of these things that I'll cover will decide whether they even choose the self hosted or the calm offering so I'm gonna do my best to cover as much as I can I did keep a high level, but we can go as deep as we need to with any questions that come up so be aware of that.

B

So here we have we'll start off with a slide deck, managing your ideas. So today, I'm going to talk about visibility, about internal public and private, on projects and groups, we're talk about group subgroups and projects and those hierarchies around them, and then we're talk. A little bit about probably a lot about authentication authorization, because I think that's where a lot of the questions are going to come in um as I go through this. Please.

B

If you have questions stop me, we can wait till the end, but I'll try to do my best to pause at moments for this. So so today we're looking at visibility, so internal versus public versus private. So there's great references and reasons why we have it this way. But, as you noticed within the internal here, internal is only for self hosted. I think you used to be on comm. They got rid of it for security reasons, and that is no longer a thing.

B

So for calm and important calm, you have public and you have private only with self hosted. You do have this option of internal so to separate a self so public projects, as you probably know, they make everything public right. So if your own self hosted and you have inbound internet access from outside, they will be seen if in public, and that is the whole reason why we had the internal it provides that level authorization to come in.

B

You still be logged in as a guest, but at least it's internal to those teams, and that hierarchy goes to be able to see everything inside of it where, with private private, we have it where it's more more explicit access to any group or project that you're going through, and so there's permissions tied to each of these by the way, and if you look into it further you'll notice that on a private guest users have some permissions and then they did and some they don't so just be aware that you'll have probably more guest permissions on internal with more functionality of a capability.

B

They can do compared to private, where it will course take those away. So just be aware of that and I put in, like I, said self self hosted with internet access inbound. This will all be seen so most customers that I've seen they either use well internal if they are using self hosted and private for calm, as that's really the only options, if you're going to do some work, any questions around this side of it pretty simple, pretty straightforward, I have.

C

B

C

I sit my public or private at the top level of my get lab comm group. How does that affect the levels below them? Yep.

B

So we're gonna get in group hierarchy in a second, but it directly affects those. So if you have projects under a public group setting all the things underneath said group will also be public, so it is. We will cover that that is important on that hierarchy. Thank you for that.

B

So here I've combined, the two I was gonna separate groups, some projects and authorization and authentication, but it seems to make sense when they're all just mashed together like this since I think everyone has a pretty good idea of group subgroups and projects, but I'll touch on that. First, just in case, that's that's not it. So within get lab. We have you know, group. As the parent group we have and I'm gonna talk, self-hosted here for a moment, we'll stay in that realm of self-hosted before I go into comm so itself.

B

How should you have parent groups and you can have as many parent groups as you need? I, don't know the limitations of how many parent groups you have I dunno on a sub group level. You can only have up to 20 I believe within the hierarchy. So maybe someone knows how many there's a limit on parents, but I don't know if there is so parent group. Once again, is that parent high level group below that you could have projects, so this sub group isn't needed. You could just have projects from that top level.

B

What we're having those customers were wanting more flexibility in their hierarchies and to provide that flexibility. We introduced the concepts of subgroup, so a skrub sub group you're able to not only have this group level permissions, but then you can do some overriding or over inheritance from the top to the sub group level, and so, for instance, if I take a group you're automatically giving guests permissions at a group level and then, if I wanted to say oh well, I don't want. You know, that's great, that it's guest but I want to see it.

B

Have some team structure within it, 16 18 BTC and have more flexibility around those hierarchies. Then I can add a sub group between the layers and once the sub groups there. Yes, the guest from will inherit from the parent down to the subgroup, but from the subgroup level. I can now overwrite and elevate the permissions given so guests here, subgroup I can start making developer and then manage my users and projects via that subgroup. We'd ever recommend to well I, say I, never recommend, maybe there's no main thing: I, never recommend.

B

You know managing your permissions around repos within the project or repo it stealth. It's too granular. It causes too many problems and for the most part when managing let's say you have 500 repos and now you're adding users at a project level that can get messy really fast and there is some limitations right around the API and what you can do there too. So just be mindful that we would never have anyone manage permissions at a project level. Try to keep it at the group level.

B

That's where we that's where we want to be at the group or the subgroup level and that's why we have the hierarchies in place, so I hope I took that down from group subgroup and project and flexibilities that provides, and why you want to do that. If not, let me know and then I'm gonna jump into now the authentication and authorization side of it, oh I, messed up. But for that let's talk about Kham Kham is a you know, force of a different color here so calm.

B

We don't call them parent groups, we call them namespaces and uncom with within self host. You can have as many parent groups or namespaces as you want on self-hosted. When it comes to calm, you only get one parent group. You only get one name space namespace per subscription. So if you have customers that want multiple parent groups or multiple namespaces they'll have to buy additional subscriptions and that that kind of goes work with self Oh Oh, sir calm, they have to use the sub group structure.

B

If they're going to be anyone of a flexible hierarchy, it's you know unless they really like spending money on additional namespaces, which I am not seeing yet so just be mindful. It's only one namespace level and then sub groups. I think limitations still apply twenty levels. So that's essentially fine and then the projects are much the same in that structure. But remember that it's private, unless they specify its public everything is private on the group structure, the project structure, all of that cool, so moving into the authentication authorization side of it.

B

So, from a self-hosted point of view, we'll start there again it's hard to dissect some of this. We support LDAP and Active Directory connections. This is an instance level. What self hosted so self host or self calm? You can do it per group, so think of the namespace group for self hosted it be the instance level for the LDAP integration and for the skin and ooofff. It's all instance level.

B

Basically, so no group ties there, but there is a way to sync and I'll show that in a minute, a sync roles or groups to roles within the self hosted, which is an important aspect for management, a lot of ways 4.com. Currently, all that supported we have sam'l 2.0 is supported. It only I believe works for there's actually a lot that it works, for we just probably don't say it for support side of it, but I've seen like jump cloud or jump, desktop I think jump cloud actually be able to integrate with it.

B

You know octa of course, and then we have a juror which is sort of separate, but the same for for sam'l with.com with sam'l, if you're only using sam'l and you're not using skim. So there is two different sits there once Kim is like provisioning sam'l if single sign-on. So it's important to delineate that and we'll have another talk separating those two out, but Sam we'll just think authentication a skim. You can think of indication and authorization in a lot of ways with the sam'l.

B

If you don't have the skim set set up, users will have to create those accounts or managers or up you know. Engineers will have to create those accounts in get lab before they can have any sort of synchronization with sam'l self-hosted. When you hook up sam'l it will it can auto provision those accounts. So it's kind of this weird mess that we have there, but but just know that users will have to be created in calm before hand if they're not using skim and what I've seen is a workaround to this and I.

B

Don't know if others have seen this to customers usually have Google auth or ooofff capabilities, and what I've seen is I'm actually hook up to the Google OAuth to create the counts in gitlab and then switch over to sam'l to syncing and linking the sam'l so might be a little trick that could be used elsewhere, but definitely workaround if they don't have octa, or these your capability require moving to skim a little bit more here.

B

So we have a sure we have octa I want you to realize that sure there is some limitations as far as what you can do from the provisioning like you can create. You can update and I. Believe you can. You can be provision users from Azure with octa. We have now in the gallery or the octagon reader marketplace. We have an application now for skim available to customers, which is great.

B

However, going back to sam'l, we have an octave sam'l application as well, but it's not in the gallery, and this is something they have to configure themselves in octa. So one application is really available. The other one you'll have to customize build, but we have documentation for both, but just realize they are separate. We are working to combine those into one octave, sam'l, skin tool.

B

So LDAP Active Directory only works for self hosted right and then, as your skin octave skin for calm. So just keep that separate there. An oauth2 actually I, don't think. There's any limitations on op2 from a.com standpoint and itself posted in Sandpoint, which is nice that I, don't it doesn't do I, don't think you do any user provisioning from oh well, no I! Guess you can from from everyone, so all up dude, no limitations that I know of notice, as I put it up here right these connections.

B

All these authentication authorization connections are at this top-level group, this parent group for calm or namespace. You cannot link it to a sub group, even though a lot of people ask for that right. Now, that's just not what we have and then of course, projects same thing. You can't link it to a project really focus on those group structures.

B

Any questions around this. This is a lot to undone. You know III apologize, so please hit me with anything you got. I haven't been checking the chat either.

D

This is just more for people who get into conversations about the business with customers that they are asking for comm of octa integration or any type of simulation, they're. Typically, looking for assertions of the provisioning I do a number of things and if you look at octa and the list of assertions they typically support or that they become available for different applications, it runs the gamut from creating users to disable users, which are the two assertions that we support.

D

Right, contribute to assertions to provide access at the group level and that's what we don't do, but a lot of customers when they think about sin.

C

D

They think about integration with the single sign-on post. That's what they're looking for so that you're.

B

D

Clarified when you're talking to them, yes,.

B

That is an important distinction. Absolutely it is because I think the expectation is that hey I have octa or I have a juror I think it's centrally centralized manage my users and and the roles within gitlab through that tool, and that is that today, that is not the case either right. So there is no group. Sync I can't create groups in octa with certain permission standards and have that linked to roles within gitlab.

B

Today they are working on that, but that is definitely something to be called out, because I think that people, you know customers will expect that and we just say: whoa whoa, it's it's really provisioning for skin-deep provisioning and then for sam'l, really single sign-on, not much group role. Sync they're happening um with with that note, though I do want to kind of take it away from from LDAP, so skim right. We don't have that role, sync octal! We don't have that role.

B

Sanford, calm and I would say that we don't really we kind of have it in in self-hosted from a Active Directory standpoint, and- and this is strictly looking at its self managed point of view you are, you do have a capability to LDAP sync, the group that you created to the role within get lab, so it's called LDAP synchronization. We do have it and I think that becomes more powerful right from self-hosted standpoint from a calm. Calm is very limited in what you can do per role here.

B

You had that capability, so here I actually have a get lab. Oh you created with global groups, and so here's my different groups that I've created I have a global admins group, and so my members of that which the various users that I provisioned and what I can do from there is go into my project. So if I go to a group, so I'm tying it to a group here and under settings LDAP synchronization.

B

What you can do is then tie that back so I can select my ad server, and this is provision in the get lab RB file. I can then select the group that I want so global admins, as we saw over here right and then I can define that to a role whether that be owner, which probably makes sense in the global admins standpoint and then adding synchronization.

B

Then it will sync those roles to those user permissions, so I think that's what everyone strives for and once when they essentially eyes manage it today, self hosted is really the the only great way of doing it. So.

B

Any other questions around this I know like I, said: I know, there's a lot going through this I. Don't.

E

Know if you haven't advised fiber skin implementation for Auto provisioning has been problematic, always had to get customer to reach out to engineering team or support him go through burn Banfi troubleshooting one client need to change how they map to external ID, and one just does not sync up so I, don't know if there any addition, Metiria that can be shared about implementation of skin in.com yeah.

B

So Cynthia from the support team actually created a YouTube video recently demoing that I don't have you've seen that yet or not. Yeah.

E

She's, the one supporting the client that we will now fold like a five weeks, so I would check with her know.

B

It so far my interactions with customers around that it's hard. It's.

E

B

We've updated our documentation to make it more clear and clean and concise, but I have seen it depending on the provider like one login or octa or jump cloud. Sometimes the details are different than than what is expected and there is some finagling or troubleshooting as to take place. I, don't have all the answers for that I myself need to throw myself into it and hurt myself to really understand the limitations around that and and what to be expected. So, ideally, we can jump into that and really start adding some value to documentation around those.

B

So I may take that on yeah.

E

So we can talk more offline. I can look up since yes, YouTube media as well. Okay,.

B

E

B

B

Yeah keep going here so I'm gonna break this. This is just a view of a common workflow that you'd see right when using groups and the hierarchy side of it right.

B

Your parent group, your subgroups and your limits, your multiple projects and then, of course, the functionality what that can be contained with each and you notice it's this kind of roll-up model that we have going first I just wanted a glimpse that I'm sure everyone's seen something like this, but just wanted to make sure that that was touched on one more thing: I wanted to go through really was around the the verticals and horizontals of this parent group, sub group hierarchy.

B

So at a parent group level just know that they can see all the sub groups below them right in that hierarchy and within the sub group itself. As you see, there's these verticals that take place, so each one is really its own little namespace or world that it works within as far as permission scope. So just be aware of that, there is some conversations around you know: I I, can't I, don't want all my customers, seeing all my groups and subgroups and there's this.

B

You know idea of breaking inheritance that they're working on and I think those are challenging. Those are really challenging to face, especially on comm. We only have one namespace to work out of and I. Don't think, there's great answers around that until they enable that functionality. You know I'll share those links as well. If those issues open around inheritance and things like that, the only other thing I want to touch on was when this gets a little weird is sharing projects and sharing groups.

B

You have the ability, so maintainer, x' and group owners have the ability to share projects with other groups, as displayed here, group owners have the ability to share groups with other groups. Now we have this thing that we call a group lock and share group lock. Basically will turn this capability of sharing projects off so that only a high-level group owner would be able to do that.

B

But what I notice on permissions is, if you turn sher group lock on that, this capability of sharing projects goes away for the maintainer and the group owner, but the group owner can still share groups with other groups.

B

So I know we don't have a lot of doctors around the sharing and the permissions I did create a merge request to update the permission table to allow for who could share groups with groups and who can share projects so that should be coming through EMR I think it just needs get approved, but but know that that's a thing right and I think that comes into play. When we start talking about SSO enforcement group managed accounts all that fun stuff that that people are now adopting.

B

So here's another example: I wanted to touch on with sharing projects with other groups. I had a customer that came to me and I guess. The expectation was that the issues from the project windshear with a group we roll into that group shared with that is not the case.

B

So if a project issues are taking or doing the work here and you're sharing that project with another group or subgroup just know that you're still working out issues here and not from the serb group level itself so little complicated, but just be aware that that's the thing and then I had the links here for the share with group lock, I'm sharing with another group and sharing project with groups um like I, said all have their own details and then we have another view: a working view of how to manage users right, guess: users inherited from that top-level subgroups take over.

B

You can override the guests permissions at the sub level, and then you can share groups between them using group owners and then, of course, never recommending to do it from a project level. On those permissions.

B

I think that's really all I had to cover I was hoping. We could dig in more I'm sure, there's a lot more questions, but I didn't touch on that. I'd like to touch on so I'll open up the floor.

A

We have one question in the doc someone would like to know: can I get lab? Comm customer changed her name space.

B

Can they change their name? Space I believe they'll have to go through support for that. So I think the answer is yes, but the only caveat to that is making sure that name. States is not already used from a previous customer.

B

So we do have this dormant name, space, action or process to go through, and sometimes customers will want a name space because it lines with their name with their company and it will already be taken, and so then we'll have to reach out to the person or individual who has that name space and and try to get them to release it if they will, if they won't, then, unfortunately, that customers have to choose a name space. That's not already taken.

E

I have a couple customers try to combine the predictive environment with user group to control who can deploy the code.

E

So it's same to word, but the deployer not supposed to see the code or do the EMR, but those permissions still provided. Is there any way to work around it.

B

So I guess I see that one more time as far as the structure that I apologize, yeah.

E

So so we will put let's a set up: a user group. We call it deployer they, their sole job is to get a profile to deploy to production and today, in order to deploy the code either you go into pipelines when you deploy tasks or make automated for the user by. If it's a manual task, the user had to go into a pipeline, so the user who's the deployer had to be a developer role, end up saying the code and you know, can do everything in fact: they're not supposed to touch source code.

E

Do it more so I'm just wondering if there is a way to work around it. Wow.

B

Yeah I would say they would probably have to I would go the route of if they're not wanting to share the code, or you want to see it probably best using the API to trigger that. Rather than going in the in a GUI and singing to court, the code itself, just an API trigger that's scripted that he can just run the script or whatever. Maybe yeah I will say, like the permissions model that we have is I'm still discovering and learning things like specially on the shared groups.

B

There's even III slide in here that I'm still having to uncover where, if you're wanting to do groups like actually put users in groups and then share that group, and let that be the control mechanism of who gets a role. There are some complications there as well. So I'll try to do my best to document it all within a slide deck to add more notes on information in there of what we find and uncover, but but yeah it's it's definitely not easy to navigate. I would say that.

B

Just to touch on I guess: I'll continue here for a little bit, I wanted to show you I'm, not sure, if everyone's seen self-hosted and how you set up the ad environment. So if you go to get lab and then get lab RB, there is a settings in here that you would fill out. You can do multiple ad servers.

B

It doesn't have to be just one and, as you show I'm showing here and enable it, but the true you put in your information around your ad server, the the base and group based kind of what I've showed here say that do reconfigure, and then you can be able to do that. Ldap, sync, here's the figurations for Omni off as well and using sam'l, and then some of the features there, but all within a good lab RB file. If you need examples of this file, just let me know.