GitLab GitLab Webinars, 23 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: GitLab Administration on SaaS

Description

Learn how to manage groups, projects, permissions, and more as you embark on your journey as an Owner in GitLab SaaS. In this session, you will learn what you can and cannot control and customize on the SaaS platform, and come out a SME in administration.

A

A

Looks like we have uh people joining us, uh we're gonna, give just another minute or so uh for folks to jump in and then we'll get started. Thank you.

A

Great, let's go ahead and get started uh like I said thanks everyone for joining us today. uh We're excited to uh to go through this session with you um just a couple of housekeeping items. uh First off uh wanted to let everyone know that this session is being recorded and it will be sent out in the coming days. So you can look forward to that. Additionally, if you have any questions that come up throughout this session, please feel free to put those in the Q a portion of Zoom.

A

We should have some time at the end to get those answered and there's there's some folks on the call that will help answer throughout as well so without further Ado I will pass it over to Sam Morris, who will be going through our content today.

B

Thanks Taylor, thank you all for joining us. I'm gonna go ahead and share my screen.

B

Great well hi everybody, my name is Sam Morris I am a tam at gitlab and I'm coming at you from Orlando Florida I am presenting on gitlab Administration on our SAS platform and what that looks like so welcome and hope you enjoy the content.

B

First off kicking it off with Ed agenda and the expected audience for the content, so overall topics of today's session we're going to give an overview of what SAS is and get lab, SAS uh comparison with our self-managed platform, which is our other, offering a general licensing items as well as the bulk of the presentation which will be on permissions roles, access visibility, auditing audit, logs and add-ons to your SAS instance.

B

The general audience for today are our folks. You know you all who are employees of companies that are using gitlab, SAS and perhaps you've been tasked with like an administrative role and you're, not quite sure how to do that on our platform. So we'll give you some good starting tips of getting kicked off, or you know, General refresher points as well out of scope for today's session is going to be. You know, detailed user provisioning, so your SSO setup or, if you're, using OCTA or something like that.

B

That's going to be outside of the scope for today, but we're going to go over mostly more on the permissions access roles and project subgroups, All, That, Jazz,.

B

So, first off I just want to kick off real quick for what is git lab in general. Gitlab is the single devops platform, where devops lifecycle tool that encompasses your entire sdlc so from source code management, git, repos, Etc to you, know, planning and tracking the progress of your projects to CI CD if you're, building and testing and delivering delivering your applications to an open source Community where you can contribute to gitlab as a platform.

B

So we are one platform that encompasses many different facets of a software development lifecycle, foreign taking it to what is git lab SAS, then and gitlab.com. And you know what does all this mean so gitlab SAS is our software as a service offering and it is available at gitlab.com.

B

uh It's comprised of a few different facets. uh Our main building blocks of SAS are the namespace. That's like the unique name for your group or your subgroup or your project where a project can be created. So if you go to any gitlab.com, you'll see the namespace for a subgroup or a group where you can create your projects.

B

The groups are used to manage projects and their permissions. So they're, essentially collections of projects, subgroups are groups within groups and they allow for separating your organization at different visibility levels, so they're extremely powerful in kind of not just nesting everything under one group, you can have different access levels Etc, so the projects are those single units of code, your code base. They help you plan your work or you do all your merger quests and your future building. You can collaborate with your teams and continuously build tests and deploy your applications at the project level.

B

Finally, users- those are individual accounts through gitlab.com and they can be members of groups and projects.

B

So kind of diving into like the pros of gitlab SAS, the infrastructure is entirely managed by gitlab, so you don't have to install any. You know you don't necessarily have to install your own Runners. You can use shared Runners for your jobs. You don't have to set up hago Etc, it's all completely managed by our engineers at gitlab.

B

Also, your versions are upgraded automatically, so we just released 15.0, for example. This is, you know, updated automatically. Every month you don't need to patch or instances you're always going to have the most secure version of gitlab.

B

The recovery is also managed by git lab. So in terms of backups and such you don't have to manage that, you make sure that your data is safe and secure. Does it go anywhere? You don't have to worry about your backups. Finally, there's no barrier to entry. You just have to pick the subscription level that you want or the license tier that you want and the number of seats that are required as well. So there is no setup required. You just sign up and get started.

B

So if we compare SAS versus self-managed, there are some key differences in making this choice and also knowing what your limitations are and your advantages are um specifically again around SAS. The infrastructure is managed by git lab in terms of high availability instance, level, backups and Recovery is all managed by us. However, if you're on self-managed you can be, you know you can use kind of whatever you want for your overall infrastructure reporting and your devops adoption reports do look different across SAS and self-manage.

B

Essentially, you can only see the group and project level adoption in any reporting is only going to be at that top level group or subgroup or project level. You can't see an instance level view because you don't really have a distance on gitlab SAS, again instance-wide settings, so any setting for users is going to be the same across the board for SAS. You don't have those um those custom settings across an instance access controls so in this case you're a customer.

B

If, as a customer, you are a group owner versus an admin, so this is very important to remember that you are not technically called an admin on getlab SAS you're called an owner across the board, so you don't necessarily have those same admin privileges which affects things like you know, using certain apis that we offer you need to have administrative access, which you don't have on gitlab SAS feature availability in the case of SAS saml ssos on premium and for self-managed, saml or ldap is free, so Different, Strokes and finally log information auditing.

B

You have a lot less visibility into auditing and logs on SAS, but you have a lot more unrestricted access on self-manage.

B

So there is an initiative to kind of have feature parity between SAS and self-managed. This is something called gitlab workspace. It is very much in the early stages. However, it's trying to achieve a top level namespace, where you can manage applying settings across all your projects and groups, aggregating data across groups and projects.

B

So it's just kind of a different way of managing your data on SAS and the idea is to move your admin area functions to groups and also have a hardware control section for self-managed instances so generally across the board, with all development at git lab.

B

We try to you, know, make things work for gitlab SAS and have that kind of trickle down into the self-managed so that we're not building for two different architectures, so in general, we're trying to move into this workspace phase, where you can have a little more of that high level control, but that is very early on in the process. However, it is in our roadmap.

B

So important to talk about support when things go wrong right um and what our Logistics look like. So in terms of SAS, our upgrade schedule is that we release the 22nd of each month. However, SAS is upgraded more frequently than those you know, minor releases and major releases that come out uh minor in the case. Every month, major every year you can't block a SAS upgrade from happening. You can't prevent a software update. Essentially, however, you are the first to get patched in the case of any security updates.

B

You know any major dot, dot, dot, dot right like large patches. Those will immediately get applied to you so you're, always on the latest version of git lab in terms of the recovery and backups. This is important to a lot of customers, knowing when is everything getting backed up?

B

How and where our production databases are backed up every 24 hours, with increa, with continuous incremental data at 60 second intervals, so pretty frequently and they're streamed into Google container service, the backups are encrypted, so your data is always secure and they follow the life cycle shown here on the screen.

B

Snapshots of our file systems are taken every four hours which primarily contains your repo data. Also has some other data as well, and these snapshots are retained for 30 days and we do promise that 99.99999 999 durability for our backups, so your data is definitely secure, but it's good to know the details when you're not managing this yourself.

B

Let's talk about support very important again, if you don't have access to those logs to triage issues on your own you're going to want to know how to interact with gitlab support and what the tiers are so here are our tiers generally. Any paying customer is on a premium or ultimate plan and both have priority support.

B

So these are different reply times, slas based on the support impact and the severity of the ticket opened. However, you do have access to those slas and support Engineers, we'll get back to you on any issues that you may have here are some of those. So in the case of an emergency, you do have a 30-minute response time, SLA right, not time to fixing the issue, but at least a response time. 24 7..

B

However, this is a little bit tricky with SAS, because technically it's implying that your instance is completely unusable or unstable since you're, not on a self-managed instance, it's hard to Define what that looks like, because if gitlab.com itself is down which you would be on gitlab.com, obviously you will be getting that emergency support, because many other customers and users are affected as well. However, if you have other issues that are completely degrading, you know your performance. You can always open a ticket.

B

Generally, you will open a highly degraded important features, unavailable, slow, Etc, a ticket, and you do get a SLA of four hours on that during the 24 5 schedule.

B

So, like I said well, what happens if gitlab.com itself is down or any other facet of it? We do track the status of gitlab.com at status.gitlab.com, which tells you, if anything is not operational and it goes past just the website of gitlab.com. It also tells you, you know: API status, get operations, many other facets, even I, think our wikis or our track in terms of their operational status. If you just check that out, you can see that you are able to see the status of everything related to our.com service.

B

You can also subscribe to updates via email. So, if you're, an administrator for your company, you might want to subscribe or subscribe to an email list so that you can get the latest updates of anything going down, or you can also configure a web hook that posts to Json payload to any URL, and you can configure slack updates. So, if anything goes down, you get notified on slack. If you have a support slack within your company, there is a lot of options for subscribing to updates on the status of gitlab.

B

Let's jump into the licensing, I have gotten questions about this before you cannot mix and match your SAS license right. So you pick. If you are a premium customer all of your users in your namespace are at the premium tier. So you can't mix and match the tier levels. You know get a couple: people an ultimate a couple: people on premium: it's not quite how it works. It's across your whole namespace right, so you can't have a separate SAS, like instance, necessarily if you have a namespace that is a premium one.

B

You pay for the subscription according to the maximum number of users assigned to that top level group, you can add or remove your users during your subscription period. But as long as that users doesn't go past. The total number that you're allotted in that given time it shouldn't exceed the subscription account.

B

So it's important to know who counts as a user right. This affects kind of you know if you're going over in your licenses, that is very important to know, and then you can do. You know license cleanup for user cleanup to mitigate those issues. Every user is counted in the seat usage, something that you can also track within gitlab as well, including users who are pending approval if they have a guest role, never mind, except with a few exceptions.

B

So if users are pending approval into a group or project, those users do not count toward your license. If you have a guest role in ultimate ultimate allows for unlimited free guest users, so you do not need to worry about those in your seat usage, any service account that is created for any bot users, bot users for projects or groups. None of those will be contributed to your overall seat usage, and you can also monitor that as well in the settings screen settings usage quotas seats to make sure that you're not going over.

B

You don't have people being added to projects and they are no longer. You know necessary there. You can manage your users from there and see who's taking up a licensee. If you have any questions about that, you can reach out to your account team, specifically a strategic account leader or an account executive, Aggie, lab and I'll sort that out for you.

B

So let's get into the bulk of our talk. How does Administration work get lab SAS and what does it mean to be an admin on gitlab.com? Again, you are not going to be called an admin on gitlab.com. Only if you're on a self-managed instance, do you have a little admin role right. So if you see that anywhere in our documentation that might not apply to you because you're not on a self-managed instance of gitlab.

B

Instead, though, you can have a role in a group and that you could be a maintainer or more likely an owner, so the owner role is very similar to an admin in capability and function. On gitlab SAS important to know, administrators can do quite a lot on the gitlab instance. They can impersonate users. So I could say that I am someone else doing something on self-managed can't do that on zest.

B

You can revoke access tokens on self-managed that are created and you, if they're created, you cannot do that on SAS and any gitlab apis that require you to be an administrator, for example, the API that allows you to revoke an access token. That is not able to be done on SAS, so you do have certain controls that are not necessarily available to you. It's important to note that creating users, so you know you've set up gitlab.

B

You need to create users, you need to add folks, you can invite users by email or you can have them, create their.

A

B

For gitlab.com and add them directly to your groups, you can also set up your skin provisioning, OCTA Azure Etc. We have some documentation on how to do that. But generally you just have to focus on users as accounts that are not managed by you kind of like. Let's say you create account, you know with your email, Etc I I can't control the account you create, but I can add you to certain projects and groups. So that's more of your goal as an administrator here until apps foreign.

B

So if you can't control exactly the user account, you can control the permissions and the roles that they have and what they can do in your corporations, projects and groups.

B

So, let's dive into the different types of roles: first off is the guest role. So guests are not contributors to private projects. They're, not you know pushing code, they're, not contributing to anything specific they can see, and they can leave comments on issues that is pretty much it and gitlab ultimate does provide those free guest users. So that's a really great option for folks who don't need so much visibility into a project, but they do want to be members of it.

B

Reporters are read-only contributors, so they can write to issues they create issues, but they can't make commits to the source code of the repository. So it's good for folks who are not you know contributing code but again need a little more visibility than at Guest level. Developers are typically the lowest level that are used in projects because they are the direct contributors. They have access to everything that allows them to go from ideation to production within a project unless something has been explicitly restricted by an owner such as you know, protecting a branch.

B

They can't push to Maine directly if the main branch was protected. Etc. So there's certain things that they cannot do, but they can be productive and do their jobs as developers with the developer role.

B

The maintainers are the super developers so they're able to they could push to the main branch if they wanted to and deploy to production, and this is often a role that is held by a manager or someone who's kind of owning a whole project and can have that higher level of trust.

B

Finally, the owners, which will be probably you all they are the group admins, so they handle the groups projects subgroups. They can give access to groups directly and they do have some destructive capabilities which we will get into.

B

So important to understand kind of how permissions work across you know both the groups and then the projects, if a member, if a user is a member of a project and the Project's parent group, the higher permission level is taken into account for the project.

B

So these permissions only go higher as they go deeper into the hierarchy which we'll visualize shortly, because it's a little bit tricky to understand, what's being explained verbally right, but if you're a developer in a group, you can be a developer, a maintainer or an owner, but not a reporter or something lower than a developer within a project in that group.

B

So again, these permissions can only go higher or greater than or equal to what you have in that group level. However, if you're an owner in a group, you can only be an owner in all subgroups and projects, so once you're an owner as you go deeper into the tiers, you are kind of an owner for everything.

B

If a user is a member of a project but not of the parent groups, they can still view the groups and their entities.

B

So you know you're not necessarily in the parent group, but you could still see an epic that might contain information from your project at that group level.

B

So our general recommendation, because folks ask you know what do I do with this. In terms of setting up, you know my permission: hierarchy as you're getting started. You want to use that principle of least privilege right. So the higher up. You are that top level group. You know your overall git lab group. Let's say you start with that lower permission and then you increase it at the deeper levels.

B

So maybe I'm a you know reporter at the highest level group, but in some lower levels, I'm a developer and maybe even at some subgroups I am a maintainer or even an owner. So we generally recommend that principle of least privilege across the board and that ties in nicely to permissions only going higher as you go deeper into the tree.

B

So you're probably wondering okay well, maybe I messed up along the way right. How do I update the member permissions once they've been set? So when you're an owner you can update group or project permissions. However, as a maintainer, you can only update the the project permissions. So that's important to note the as an owner in a top level group, you can adjust the maximum role in a drop down.

B

If you look at the list of numbers in the project, you can adjust the role or you can invite members directly into that group and ask them to be a certain level of permission. So someone might directly invite me. Sam has a maintainer something like that again same with the subgroup level same with the project level, adjusting that Max role drop down or inviting directly, and we should note that owner can only invite up to owner access in a group and maintainer and a project. So I can't make someone owner and owner of a project.

B

You can only be an owner in a group maintainer, you can add someone to a project, I can't add them to a group or a subgroup, but I can't add them to my project as a maintainer and proceed the same way with the maximum roll drop down. We're inviting them directly into the project and a maintainer can up to can invite up to maintain or access in a project. So I could not invite someone to be an owner right or something higher than that, and only owners and maintainers can actually update group or project permissions.

B

So as a developer, I would not be able to update someone's permission level. I have to have at least that maintainer access to do that and the maximum role drop down is only enabled for direct memberships. So if I did not directly invite you to a project that drop down is not going to be accessible, I'd have to directly invite you by you.

A

Know, email or.

B

Your gitlab username and then that Max role drop down would be enabled look, I see what that looks like shortly.

B

Here's the visualization right. So this is me: I am Sam I Am a developer at a top level group for some organization and I am a member of subgroup. One I inherited the developer permission from that top level group and within subgroup one. There are two immediate things: I can see, which is subgroup two and Project B.

B

So, let's dive into subgroup, two I am a maintainer in subgroup two, because I was added directly as a maintainer to and within subgroup 2. There is one project a where I am a maintainer which I inherited from subgroup two, so you can kind of see that the only way my permission level changed was that I was directly invited at a higher level of permission which in this case maintainer is higher.

A

Than developer, everything.

B

Makes sense, however, I'm still just a developer in Project B, because I inherited that from my top level group. So it's important to note that I inherited the top level group permission and not from subgroup one. So it would show up as me, inheriting from top level group, because nothing changed between top level group and my inherited permission and subgroup one so smart and knows that I was still over all the way at top level group and that hasn't changed. It just propagated down to Project B.

B

So, let's see what that looks like in gitlab.com and not just in a diagram.

B

So here I am I'm. Sam I was added as a direct member as a developer here uh to the top level group Sam top level Group by this owner. Who is also me, but we're going to be looking at this top user here and you can see that as an owner, I think I believe I'm logged in as the owner here I could remove um the developer Sam from this group. If I wanted to, but I don't want to.

B

So you can see the developer permission trickles into subgroup one. So if I dive from the Sam topical group into subgroup one and look at the group members I can see that I am still a developer. In my maximum role. I can't adjust in the drop down here because I inherited this permission from top level group.

B

And it shows my access was granted one minute ago, in this case by it's a little confusing because they're, both Sam Morris, but it was um I- was granted by the owner of Sam Morris, who gave me access to subgroup one.

B

So you can see that my developer permission stays the same all the way from the top level group into project C. So now I am inside a project. I am no longer in a group. You can see project members right here and I'm still a developer and my source is still a top level group, as nothing has changed from then I'm still listed as a developer.

B

However, I was directly added as a maintainer to subgroup 2.. So now we're in subgroup 2 within the top level group, and you can see that the source change from Sam top level group to direct member. So someone directly added me, you can see when the access were granted in by whom and then this maximum roll drop down is here. So I can only see this Max rule drop down because I'm logged into my owner account and I could adjust it here to a different level of access.

B

And you can see that I inherited my maintainer permission from subgroup 2.. So since that was changed to container I can now see it within project a here that I am a maintainer and that the source has changed to subgroup one and within subgroup. One subgroup, two I was changed to a maintainer previously and now I propagate it down into project A's role.

B

So how do we add and change owners of a group right? So let's say you know what you want to make someone into an owner. They want that same administrative permission that you might have that is possible. You're onboarding, a new admin. You need them to have the owner permission role. How do we do this? Owners can only be added at the group level, so they can't be added at the project level. Only at the group or or subgroup level, and once an owner is main owner.

B

They cannot modify their membership in projects or be reinvited the project as anything lower than owner. So again you will stay at owner and you can't change your permission level. Even as an owner, you will only be an owner of any projects and groups once you are added to the top level group as an owner.

B

So at the group level an owner can leave or decrease the membership of a different owner, but they cannot adjust to their own membership in the projects and this new permission will trickle down into subgroups and projects. So at the group level you can change it, but you can't change it to project level. At the project level, you can leave the project right, so you're no longer a member of the project, but you couldn't have decreased your membership there. You just have to leave so group bubble, leave or decrease tragedy level leave the project happens.

B

If you accidentally made someone an owner in a group that could be pretty catastrophic right owners can transfer namespaces, they can delete projects right. So you know it's a lot of power.

A

B

So you want to be able to switch that back. So if you make someone an owner in a group, they become an owner of all those subgroups and projects, so you can just switch them back to that original permission level at the group level, and then the previous permissions will actually restore, including any direct memberships versus inherited memberships. So you won't have to go back through and check all your audit logs of what were they before right. That would be pretty difficult to trace.

B

So thankfully, just go back to that group and you switch their membership back to what it was and the permissions will restore from there um pretty cleanly.

B

Let's get into user Management on SAS, some customers ask how to identify inactive users right, which would be super helpful, especially if you are trying to you know clean up the number of licensed seats you're consuming. You want to know if people aren't active in gitlab SAS right for your projects in your group specifically, so, unfortunately, there is no automated way to do this on gitlab.com, because again you want to think of a user.

B

As a member that could be a member of any project or group on gitlab.com, you could be a member of gitlabs group. You can be a member of your company's group right, so you know there isn't really a clean way to kind of track, what you're a member of right, because you're just a user across an entire SAS platform. So there's no automated way to do this.

B

You can retrieve the last activity on field from namespace Members via the billable members API. That is a possibility for seeing the last activity on field in the UI. You can sort the list of users in a group by their last activity. But again, this is generic and its activity across any group or project on gitlab.com. So if I had my own personal projects, I was doing or my own sandbox stuff.

B

You would see that last activity on um and not necessarily the last activity in that project or group right so still not a foolproof approach. Unless you can guarantee that these users are not anywhere else. On.Com I can also review the group information and activity to see who's interacting with any issue project, epic or subgroup in the group and decide who to remove from there. It's probably your best approach if you want to just see who's active, but it doesn't tell you who is inactive.

B

It just kind of shows that they weren't active in recent history right, but you can go through and see the activity across your projects and groups by checking group information and then the activity section.

B

Yeah also, how can you prevent users from being added at higher levels right because, obviously, it's great principle of least privilege? We want to be able to add people at higher levels, so there are restrictions in who can grant what permission again. So an owner can manage permissions at the group level and only owners can make other owners at the group level.

B

So there is some, you know, access, control and a sense that you don't want to give people owner permission, but you can revoke it as an owner, but you know there are restrictions of who can kind of do what so that does help owners and maintainers can manage memberships at the project level. So again, you would not be giving people owner or maintainer privileges unless you knew that they were.

B

You know good to add users at certain permission, levels, advocator or even odor levels of things, and once a user is a member of a group or project, they can have their permission level modified to be the same or higher level.

B

But you can prevent a user from automatically inheriting permissions from a group by adding them as a minimal access user so that these permissions don't propagate into the subgroups and projects within that group. So that is an option to add a user as a minimal access user.

B

So in terms of visibility and access control, so what does a visibility mean? On.Com generally, we only have two permission or visibility levels, including public and private visibility. So it is unlikely. Any of you will be making public projects, but it is good to know that it is an option of what it entails. So public projects are projects that can be cloned without any Authentication and they're visible to all gitlab.com users, even when they're not signed into an account and anyone is at least a guest in a public project. So those are unlikely for corporations.

B

However, good to know what a public project is you pretty much never want to set a product or group to public in a private projects are cloned and viewed only by project members except guests, so guests cannot clone or view projects. However, if you are any level above that, you do have some whatever power, if you were added directly to a private group or a private project. So generally, you want to keep everything private.

B

So another topic here is: what is audit Trails look like with SAS. When you don't have access to infrastructure, you don't have access to those detailed logs. What do you have so on the premium and ultimate tier which yeah many customers are on? You do have access to audit events which are Super, robust and very helpful, so audit events can help you see if a permission level has changed and when you see you click on the audit event, you can see the author of the change so who changed someone's permission level.

B

uh What the action exactly was the Target or whose permission changed the IP address for this change occurred and the date. So here's an example someone change access level from maintainer to owner with expiry remaining unchanged. That never expires. So I can tell you the expiry date that they might have set the actual permission level of that the person was at to what they.

A

B

And who authored the change? This is very helpful in terms of auditing and making sure that there are no Bad actors who are changing people's permission levels to something higher, which again, we do have some restrictions on, but uh you know things happen. You want to be prepared for that logging. So this is the audit event that's available to you.

B

There's also a lot of other audit events that are useful. So I've listed some here you can see if a project was created if it was deleted, which only owners can do but good to know if it was renamed or moved to a different path.

B

You can see if a user was added to a project and at what permissions again permissions changing for a user if a user was removed from a project.

B

So if you recall earlier, I could have clicked like remove member and take someone out of a group or project right, but you have an odd event that tracks, if that occurs, if a project export was downloaded, so you know you can export projects to many different formats say like I, just dot zip, you can see if an export was downloaded by someone which might be a bad actor or a malicious person trying to download code bases. They have restrictions on that. That's something that you can track.

B

Also two-factor, authentication enforcement or if the grace period has changed for that, so we highly recommend setting up uh multi-factor Authentication. So there's an odd event. If a you know, project group set up that uh or made a requirement to set up 2fa and also you can change the grace period by which someone has to sign up. So you can check if that has changed and to what with an audit event, and we have both project and group audit events, you can take a look at those and see what info is available to you.

B

We also have apis where you can interact with these audit events as well, which is my next slide. So how do we automate this? How do we check when things are happening? You know I, don't necessarily want to go into the UI and be the audit event fair enough. So the odd event API and streaming are two features that you can consider.

B

The API allows you to retrieve all as well as specific group and project audit events. So if you run a script, that's checking for certain events. You can do that. There's a lot of ways you can Leverage The API calls.

B

So in the case of project events, maintainers and above can retrieve project audit events for all users and developers can retrieve ad events based on their own actions. If I was a developer, I couldn't see everything, but I could see my own audit event. If I changed the permission of someone, if I you know, did something within my well I guess: I couldn't if I was a developer, but if I did anything that an odd event would track, I could see it for myself. A maintainer could see for everybody similar with the group.

B

Only owners can retrieve group audit events for all users and developers and maintainers can retrieve audit events based on their individual actions.

B

So again, you can see what you're doing but can't see everything on Advanced streaming, so this is only for ultimate customers. However, if you are an ultimate customer available to you, so the event streaming allows owners at the top level groups to send HTTP endpoint to receive all odd events about a group, it's subgroups and its projects as a structured Json. So if you want to stream your events, you can configure that, but you do have to be on the ultimate tier for that.

B

So, finally, we're gonna get into some SAS add-ons right, including CI and CD minutes. So I've had a few customers run into this. Where you know they went past their allotted number of CI CD minutes, so you can pay ten dollars for an additional 10. 000 minutes. You just need a credit card. You can pay for extra minutes to run your jobs.

B

uh The CI CD minutes are the execution time for your pipelines on gitlab shared Runners. So if you're using our infrastructure for your Runners, you can use your own self-managed Runners set them up wherever. However, if you're using our shared ones, uh you will need to stay within a certain limit of minutes. You can buy more, and these purchases are one time they don't renew annually or anything like that. Just you know, as needed ad hoc, you can buy some extra minutes for your jobs.

B

You can also purchase additional storage, so it's 60 per 10 gigabytes of storage and you can kind of check if you need to do that by looking at your usage quotas uh within your group. So you just go in your group and then you check your settings, usage quotas, storage and then you can purchase more storage from there. The storage subscriptions. Do you renew automatically so I believe it's annually. You will be charged again if you added the 10 or more gigabytes of storage.

B

um So it's not the one-time part, just like the CI CD minutes. But if you need more infrastructure you can pay for. It is the important note here just an additional cost.

B

So that's it for administration on gitlab SAS, thanks for your time today and I'll pause for any questions.

A

Great thank you Sam. um Before we jump into the questions which we do have a few I'm going to pop open. A poll right now would love to uh get feedback from uh from all of you on on how today's session went uh just a couple questions. So if you take a minute to answer that that'd be great um and from there we will jump into some q a um so Sam.

A

The first question that came in here is there a way to add users to a group without automatically adding them to other projects or subgroups.

B

Yes, there is a way to do that. So, if you add a user as minimal minimal access, that is kind of the trick for not adding them automatically into subgroups and projects underneath a group, so they will inherit those permissions. You can just add them directly. That's kind of like a terminal um permission.

B

A

um Next one we have here, how do I access the admin panel on gitlab.com.

B

Yeah definitely so the admin panel or admin area is a great feature. It's on our self-managed offering. So if you want to access that, you can do so on a self-managed instance. However, it's not something that's available on gitlab.com, so you know. In that case you have to manage. You know permissions and roles from the groups and projects. So you can't access a direct admin area, but hopefully gitlab workspace will kind of cover that once we start achieving the parity between SAS and self-manage and you'll have those admin area functionalities on SAS.

B

But for now it's not possible.

A

Okay, um last one I'm seeing here what is a good role for someone who doesn't need access to the code base more of an executive type.

B

So generally, we recommend a reporter level access for that, so that you don't have to be a contributing code or viewing it. You can just leave comments on issues, especially to track progress of things. We do have a good mapping between the permissions and roles and the actual roles within a business like what you know a business analysis of me. What an executive would need so generally our guidance for if someone doesn't need to be hands on keyboard or developing anything, it could be set as a reporter.

A

Great, thank you Sam.

A

um Well with that I I think we'll wrap up now appreciate everyone's time today, um as I mentioned at the beginning, uh keep an eye out for the uh for the recording and the deck we'll be sending that out uh in the next day or two um and keep an eye out for for future sessions like this we're glad you joined us today have a good rest. Your day.

B

Thank you, foreign.