1 of 38

GitLab Admin Training

Getting Started with GitLab Admin

2 of 38

2

The One

DevOps Platform

for software innovation

Project planning
Source code management
Continuous integration
Infrastructure configuration
Incident monitoring
Application security
And so much more...

Business

Developers

Security

Operations

One user interface

Unified data model

Plan

Create

Monitor

Package

Release

Manage

Verify

Secure

Configure

Protect

GitLab is the first and only true DevOps Platform. �

It’s a single application with one user interface, a unified data store, one permission model, and security embedded within the DevOps lifecycle.

That combination allows you to do something you simply can’t do with any of the previous phases to reach your business goals.

�In a single application, it combines the ability to:

Plan
Develop
Secure
Release
Operate and monitor software in a single application that is easier to use and maintain, with complete visibility and traceability.

With GitLab as a partner, EVERY team in your organization can collaborate in a SINGLE solution to manage the end-to-end development lifecycle, delivering more value faster, increasing visibility, quality, and security, and removing context switching and non-value-generating tasks.

3 of 38

GitLab Recommended Process

Manage	Plan	Create	Verify	Package	Secure	Release	Configure	Monitor	Protect

Create Merge Request

Automated�Build / Test

Collaboration & Review

Approval

Push Code

Push Fixes

Review App

Assign Issue

Scan

Release

Merge Accepted

Deploy

Epics

Milestones

Issues

TLDR for this slide: Provide the audience with the overarching view of where CI/CD fits into the GitLab process

Set the context for this infographic by saying something like: there are many steps to get from an idea to a production solution. This graphic shows the GitLab Flow process. This process can apply to anything - a bug, a feature, a security vulnerability.
Point out that the two grey lines represent two branches, with all work being done on the Feature Branch
Briefly take the audience through the process from issue to the security dashboards.

Git allows a wide variety of branching strategies and workflows. Because of this, many organizations end up with workflows that are too complicated, not clearly defined, or not integrated with issue tracking systems. Therefore, we propose GitLab flow as a clearly defined set of best practices. It combines feature-driven development and feature branches with issue tracking. The GitLab flow is a clearly defined set of best practices.

A simplified branching strategy
All features and fixes first go to main
Allows for ‘production’ or ‘stable’ branches
Bug fixes/hot fix patches are cherry-picked from main

We recommend for DevOps teams to follow the GitLab Flow process while using GitLab capabilities within a concurrent development lifecycle.

The GitLab application is based around a feature branch based workflow.

The Merge Request, and can be thought of as the core of the product.

The gray line at the bottom of the slide shows the main branch. Notice another gray line that breaks off the main branch and eventually ties back into main. This is what’s known as a feature branch. The feature branch represents the source code pattern where a developer opens the branch and begins working on a new feature and that work is soon integrated into the main branch.

We begin by creating a discrete unit of work by creating an issue. (think of it as a ticket) We assign the issue to a team member.

From the issue; we spawn a feature branch, think of it as a parallel line of development. Developers move to the a branch to interact with the request. GitLab provides updates and notifications on the state of your issue automatically. If you work with a feature branch for more than a few hours, its a best practice to share the result with your immediate team. It maynot be ready to be merged, but feedback is welcomed. Your team can make comments on the merge request in general, or on specific lines. The merge request serves as code review tool, and no separate tool should be needed. When your comfortable with your work, and the comments made, you can assign it to someone who knows the most about the code base, or someone that has permission to merge into the main branch. We have code review and conflict resolution built into the platform for merge conflicts.

The commit kicks off an automated Continuous Integration pipeline that runs and goes thru the steps to the right of the slide. The advantage is that developers have visibility into what going on in the cycle.

https://docs.gitlab.com/ee/topics/gitlab_flow.html#introduction-to-gitlab-flow

4 of 38

GitLab Workflow Components

GitLab Component	Function	Also known as...
Project	The core building block where work is organized, managed, tracked and delivered to help the team to collaborate and plan work in the form of issues.	Repository
Group	A collection of projects and subgroups. They are like folders.	Project
Issue	An issue is part of a project. It is the fundamental planning object where the team documents the use case in the description, discusses the approach, estimates the size/effort (issue weight), tracks actual time/effort, assigns work, and tracks progress.	Story, Narrative
Epic	A collection of related issues across different groups and projects to help organize by theme
Merge Request	The linkage between the issue and the actual code changes. Captures the design, implementation details (code changes), discussions (code reviews), approvals, testing (CI Pipeline), and security scans.	Pull Request
Label	Used to tag and track work for a project or group and associate issues with different initiatives
Board	A visual listing of projects and issues useful for teams to manage their backlog of work, prioritize items, and move issues to the team or specific stage in the project.
Milestone / Iteration	A sprint or deliverable(s), helping you organize code, issues, and merge requests into a cohesive group	Release / Sprint
Roadmap	A visual representation of the various epics for the group

5 of 38

GitLab Hierarchy

Group

Sub Group

Project

Issue

Project

Participants

Comments

Assignments

Issue

6 of 38

GitLab Installation

7 of 38

GitLab Installation (Ubuntu 24.04) (1/2)

Enable SSH and open firewall ports:

systemctl enable --now ssh
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Add Gitlab package repository:

sudo apt install -y curl
curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

8 of 38

GitLab Installation (Ubuntu 24.04) (2/2)

Install the package:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce
Gitlab generate a random password. After successful installation, you can retrieve password in the directory
The password is stored in /etc/gitla/initial_root_password for 24 hours.
After 24 hours, this file is automatically removed for security reasons

9 of 38

Admin Tour & Instance Hardening

10 of 38

First checks

First step in making your installation secure:

Sign in using admin account -> Admin Area (wrench icon)
Verify version (Admin -> Overview -> Dashboard)
Set Visibility & Sign-ups restrictions (Admin -> Settings -> General -> Visibility and access controls). Disable public sign-ups if required by policy.

11 of 38

Instance basics

External URL & HTTPS are defined in /etc/gitlab/gitlab.rb

(external_url ‘https://git.fotia.com.my’)

Reconfigure after changes
sudo gitlab-ctl reconfigure
sudo gitlab-ctl status

12 of 38

Configure GitLab

13 of 38

SMTP

Configure SMTP in Omnibus

Edit /etc/gitlab/gitlab.rb and add/adjust:
Apply changes: gitlab-ctl reconfigure
Send a test email: Notify.test_email('you@yourdomain.com', 'GitLab SMTP training', 'It works').deliver_now

gitlab_rails['smtp_enable'] = true

gitlab_rails['smtp_address'] = "smtp.yourprovider.com"

gitlab_rails['smtp_port'] = 587 # use 465 for SMTPS

gitlab_rails['smtp_user_name'] = "smtp-user"

gitlab_rails['smtp_password'] = "smtp-password"

gitlab_rails['smtp_domain'] = "yourdomain.com"

gitlab_rails['smtp_authentication'] = "login"

gitlab_rails['smtp_enable_starttls_auto'] = true # for 587/STARTTLS

# For 465/SMTPS also set:

# gitlab_rails['smtp_tls'] = true

# Sender identity

gitlab_rails['gitlab_email_from'] = 'gitlab@yourdomain.com'

gitlab_rails['gitlab_email_reply_to'] = 'noreply@yourdomain.com'

14 of 38

Container Registry

Separate domain

Configure Registry to use its own domain

Place your TLS certificate and key in /etc/gitlab/ssl/<registry.fotia.com.my>.crt and , /etc/gitlab/ssl/<registry.fotia.com.my>.key
Make sure the information is correct: chmod 600 /etc/gitlab/ssl/<registry.gitlab.example.com>.*
After the TLS certificate is in place, edit/etc/gitlab/gitlab.rb: registry_external_url ‘https://registry.gitlab.example.com’

15 of 38

Change Time Zone

Default time zone in GitLab is UTC, but you can change it to your likin

View available timezones: timedatectl list-timezones
Edit /etc/gitlab/gitlab.rb: gitlab_rails[‘time_zone’] = ‘Asia/Kuala_Lumpur’
Save the file, then reconfigure and restart GitLab:
Sudo gitlab-ctl reconfigure
Sudo gitlab-ctl restart

16 of 38

Administer users

17 of 38

Roles & permissions

GitLab Roles

From least to most permissions

No access
Minimal Access
Guest
Reporter
Developer
Maintainer
Owner

18 of 38

Roles explained

Minimal access	Guest users	Reporters	Developers	Maintainers	Owners
Only on top-level group	Free on Ultimate	Read-only contributors	Full project access	Full project access	Owners are group/project admins
Not counted against license	Limited read-only access	Can’t write to the repository	Can’t commit / merge to protected branch	Can push to master & deploy to production	Have destructive privileges on project/group
Need to be given explicit access to projects	Can comment on issues & MR’s	Can comment on issues & MR’s	Can’t deploy yo protected environments	Own/maintains the codebase	Can give users access to groups / projects
	Only applies on private & internal projects		No admin privileges	Limited admin privileges on project / group	Can elevate users in paid role

19 of 38

Create users

Every person who needs access to your GitLab projects requires an account. User accounts control access permissions, track contributions, and maintain security across your instance.

You can create user accounts in GitLab in different ways:

Self-registration for teams who value autonomy
Admin-driven creation for controlled onboarding
Authentication integration for enterprise environments
Console access for automation and bulk operations

20 of 38

Create a user in the Admin

To create a user:

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
Select New user.
In the Account section, enter the required account information.
Optional. In the Access section, configure any project limits or user type settings.
Select Create user.

GitLab sends an email to the user with a sign-in link, and the user must create a password when they first sign in. You can also directly set a password for the user

21 of 38

Reset user passwords

To reset a user password in the UI:

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
Identify a user account to update, select Edit.
In the Password section, enter and confirm a new password.
Select Save changes.

GitLab updates the user password

22 of 38

Locked user accounts

Gitlab locks a user account after the user unsuccessfully attempts to sign in several times. By default, user accounts are locked after 10 failed sign-in attempts. Accounts are unlocked automatically after 10 minutes.

To unlock an account from the Admin area:

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
Use the search bar to find the locked user.
From the User administration dropdown list, select Unlock.

The user can now sign in.

23 of 38

External User

Commonly created when a user outside an organization needs access to only a specific project. When assigning a role to an external user, you should be aware of the project visibility and permissions associated with the role.

Can access public groups, projects, and snippets.
Can access internal or private groups and projects where they are members.
Can create subgroups, projects, and snippets in any top-level groups where they are members.
Cannot create groups, projects, or snippets in their personal namespace.

24 of 38

External User

Create an external user

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
Select New user.
In the Account section, enter the required account information.
Optional. In the Access section, configure any project limits or user type settings.
Select the External checkbox.
Select Create user.

25 of 38

Moderate users (1/3)

View users by type

Filter the list of users to display only human or bot users.

To view users by type:

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
In the search box, enter a filter.
To display human users, enter Type=Humans.
To display bot users, enter Type=Bots.
Press Enter

26 of 38

Moderate users (2/3)

Users pending approval

When a user registers for an account while this setting is enabled:

The user is placed in a Pending approval state.
The user sees a message telling them their account is awaiting approval by an administrator.

A user pending approval:

Is functionally identical to a blocked user.
Cannot sign in.
Cannot access Git repositories or the GitLab API.
Does not receive any notifications from GitLab.
Does not consume a seat.

An administrator must approve their sign up to allow them to sign in

27 of 38

Moderate users (3/3)

Approve or reject a user sign up

A user sign up pending approval can be approved or rejected from the Admin area.

To approve or reject a user sign up:

On the left sidebar, at the bottom, select Admin.
Select Overview > Users.
In the search box, filter by State=Pending approval and press Enter
For the user sign up you want to approve or reject, select the vertical ellipsis, then Approve or Reject

Approve a user:

Activates their account.
Changes the user’s state to active.
Consumes a subscription seat.

Rejecting a user:

Prevents the user from signing in or accessing instance information.
Deletes the user.

28 of 38

Review abuse reports (1/2)

Receive notification of abuse reports by email

To receive notifications of new abuse reports by email:

On the left sidebar, at the bottom, select Admin.
Select Settings > Reporting.
Expand the Abuse reports section.
Provide an email address and select Save changes.

29 of 38

Review abuse reports (2/2)

Resolve abuse reports

To access abuse reports:

On the left sidebar, at the bottom, select Admin.
Select Abuse reports.

There are four ways to resolve an abuse report, with a button for each method:

Remove user & report: i) Deletes the reported user from the instance. Ii) Removes the abuse report from the list.
Block user.
Remove report: i) Removes the abuse report from the list. Ii)Removes access restrictions for the reported user.
Trust user: i)Allows the user to create issues, notes, snippets, and merge requests without being blocked for spam. ii)Prevents abuse reports from being created for this user.

30 of 38

Broadcast messages (1/2)

GitLab can display two types of broadcast messages to users of a GitLab instance:

1) Banners

Banners are shown on the top of a page:

2) Notifications

GitLab shows notifications on the bottom right of a page

31 of 38

Broadcast messages (2/2)

Add a broadcast message

To add a broadcast message:

On the left sidebar, at the bottom, select Admin.
Select Messages.
On the right, select Add new message.
Add your Message text
For Type, select `banner` or `notification`
Select a Theme. Default is `indigo`
To enable users to dismiss the broadcast message, select Dismissable.
Optional. To skip showing the broadcast message in the command line as a Git remote response, select clear the Git remote responses.
Optional. To show the message only to a subset of users, select Target broadcast message:
If required, select the Target roles to show the broadcast message to
Select a date and time (UTC) for the message to start and end.
Select Add broadcast message.

32 of 38

Maintain GitLab

33 of 38

Backup and Restore

Back up GitLab

GitLab backups protect your data and help with disaster recovery

sudo gitlab-backup create
sudo gitlab-ctl backup-etc

Restore GitLab for Linux

Ensure your backup tar file is in the backup directory

sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git:git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
gitlab-ctl status
sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce
sudo gitlab-ctl reconfigure
sudo gitlab-ctl start
sudo gitlab-rake gitlab:check SANITIZE=true
After the restore is completed, run: sudo gitlab-rails dbconsole --database main
SET STATEMENT_TIMEOUT=0 ; ANALYZE VERBOSE;

Automate Backup

sudo crontab -e -u root

0 2 * * * /usr/bin/gitlab-backup create CRON=1

15 2 * * * /opt/gitlab/bin/gitlab-ctl backup-etc && cp $(ls -t /etc/gitlab/config_backup | head -n1) /secret/gitlab/backups/

34 of 38

Restart GitLab

Restart a Linux package installation

Ensure your backup tar file is in the backup directory

sudo gitlab-ctl restart

Restart a component separately

Append service name to the `restart` command

sudo gitlab-ctl restart nginx
Sudo gitlab-ctl status

35 of 38

Secure GitLab

36 of 38

Enforce two-factor authentication (2FA)

Enforce 2FA for all users

You can use UI to enforce 2FA for all users:

On the left sidebar, at the bottom, select Admin.
Select Settings > General.
Expand Sign-in restrictions:
Select Enforce two-factor authentication to enable this feature.
In Two-factor grace period, enter a number of hours. If you want to enforce 2FA on next sign-in attempt, enter 0

37 of 38

Enforce two-factor authentication (2FA)

Enforce 2FA for Admininstrator users

You can use UI to enforce 2FA for all users:

On the left sidebar, at the bottom, select Admin.
Select Settings > General.
Expand Sign-in restrictions:
Select Require administrators to enable 2FA
In Two-factor grace period, enter a number of hours. If you want to enforce 2FA on next sign-in attempt, enter 0
Select Save changes

38 of 38

Q&A