Day 2: GitLab Projects, Groups & Secure Authentication

Search for a command to run...

No comments yet. Be the first to comment.
Master GitLab from scratch with this complete step-by-step DevOps series. Learn GitLab fundamentals, repositories, branching, merge requests, CI/CD pipelines, GitLab Runner, Docker, Kubernetes integration, security, deployments, and real-world DevOps workflows. Whether you're a beginner or preparing for DevOps interviews, this series will help you gain practical GitLab skills through hands-on examples and projects.
Import Repositories, Mirroring & Repository Management Best Practices ๐ Introduction In the previous articles, we learned the fundamentals of GitLab, created projects, and configured secure authentic
Master GitLab CI/CD Variables, Secrets Management, Artifacts & Best Practices ๐ Introduction In the previous article, we learned how GitLab Runners execute CI/CD pipelines and how to configure Self-H

Learn GitLab Runners, Hosted vs Self-Hosted Runners, Runner Registration, Tags, Pipeline Editor & Parallel Jobs ๐ Introduction In the previous article, we created our first GitLab CI/CD pipeline and

Learn Continuous Integration, Continuous Delivery, Pipelines, Stages, Jobs & .gitlab-ci.yml ๐ Introduction In the previous articles, we explored GitLab fundamentals, repository management, and collab

Learn Docker Scout, Multi-Stage Builds, Docker Hardened Images (DHI), SBOM, Docker Model Runner, Ask Gordon AI, and production-ready container security through practical, real-world examples. Introduc

Import Repositories, Mirroring & Repository Management Best Practices ๐ Introduction In the previous articles, we learned the fundamentals of GitLab, created projects, and configured secure authentic

Learn how GitLab organizes repositories using Groups and Projects, and understand how to securely authenticate using Personal Access Tokens (PAT), SSH Keys, and Single Sign-On (SSO).
In the previous article, we explored the fundamentals of GitLab, including its architecture, deployment models, and how it compares with GitHub and Bitbucket.
Now that we have a solid understanding of GitLab, it's time to learn how repositories are organized and how developers securely access them.
Whether you're working individually or as part of a large development team, understanding Groups, Projects, and authentication methods is essential. These concepts help organizations manage repositories efficiently while ensuring secure collaboration across teams.
In this article, we'll explore how GitLab organizes projects, how authentication works, and how to securely connect to GitLab repositories using Personal Access Tokens (PAT) and SSH Keys. We'll also learn how to configure an AWS EC2 instance to communicate with GitLab using SSH authentication.
By the end of this guide, you'll be able to organize projects like a professional DevOps engineer and securely interact with GitLab repositories.
After completing this article, you'll understand:
โ What are GitLab Groups?
โ What are GitLab Projects?
โ Difference between Groups and Projects
โ GitLab Project Structure
โ Git Authentication
โ Personal Access Tokens (PAT)
โ SSH Keys
โ Single Sign-On (SSO)
โ SSH Authentication Setup
โ Cloning a Repository using SSH
Before continuing, make sure you have:
A GitLab Account
Git Installed on your system
Basic knowledge of Git commands
A Linux machine or AWS EC2 instance (optional for practice)
As organizations grow, managing hundreds of repositories individually becomes difficult. To solve this problem, GitLab provides Groups.
A Group is a container that helps organize multiple related projects under a single team or organization. Instead of managing users and permissions separately for each repository, administrators can manage everything at the group level.
For example, if a company has separate repositories for a frontend application, backend API, Kubernetes manifests, and Terraform configurations, all of them can be placed inside a single group.
This approach makes collaboration easier, simplifies permission management, and keeps projects well organized.
Imagine your company is called ABC Technologies.
Inside the company, there's a DevOps Team responsible for managing cloud infrastructure and application deployments.
The DevOps team may create a single GitLab Group called DevOps-Team, which contains multiple projects.
Using Groups provides several advantages:
Better project organization
Easier permission management
Improved collaboration
Simplified administration
Centralized access control
Groups are especially useful for organizations managing multiple teams and repositories.
A Project is the place where your actual application or source code is stored in GitLab. Every project contains everything related to a specific application, service, or repository, including its source code, branches, commits, Merge Requests, issues, and CI/CD pipelines.
In simple terms, if a Group represents a team or organization, then a Project represents the actual application or repository that the team is working on.
For example, a company may have different applications such as a frontend website, backend API, Kubernetes manifests, and Terraform code. Each of these would typically be created as a separate project within the same GitLab Group.
Let's continue with the previous example.
Suppose your organization has a Group named DevOps-Team.
Inside this Group, you can create multiple projects, each serving a different purpose.
Projects help organize your work efficiently by keeping each application or service in its own dedicated repository.
Some benefits of using Projects include:
Store source code securely
Manage Git branches and commits
Collaborate using Merge Requests
Automate CI/CD pipelines
Track issues and bugs
Maintain project documentation
Whether you're developing a simple application or managing enterprise infrastructure, every repository in GitLab is created as a Project.
One of the most common questions beginners ask is:
"What is the difference between a Group and a Project?"
The answer is simple.
A Group is used to organize and manage multiple related projects, whereas a Project is where the actual application or source code resides.
Think of a Group as a company department and a Project as the individual applications that department is responsible for.
For example, a DevOps team may manage several applications, infrastructure code, and automation scripts. Instead of creating everything separately, they organize all related repositories under a single Group.
Create a Group when:
You have multiple related repositories.
Multiple developers work on different projects.
You want centralized permission management.
You're managing projects for a team or organization.
Create a Project when:
You're starting a new application.
You need a separate Git repository.
You want an independent CI/CD pipeline.
You need to track issues and manage code for a specific application.
Before you can clone, push, or pull code from a GitLab repository, GitLab must verify your identity. This process is known as Git Authentication.
In the past, many Git hosting platforms allowed users to authenticate using their account password. However, this approach was not secure because passwords could be exposed or misused.
To improve security, GitLab no longer supports using your account password for Git operations over HTTPS. Instead, it uses more secure authentication methods such as Personal Access Tokens (PAT), SSH Keys, and Single Sign-On (SSO).
These authentication methods help protect repositories while ensuring that only authorized users can access and modify the source code.
GitLab provides three primary authentication methods:
SSH authentication uses a public-private key pair to securely connect your system with GitLab. Once configured, you can clone, pull, and push repositories without entering your credentials every time.
Best for: Developers and DevOps Engineers who work with Git repositories regularly.
A Personal Access Token acts as a secure replacement for your account password when performing Git operations over HTTPS.
Instead of entering your GitLab password, you use the generated token.
Best for: HTTPS-based Git operations and API integrations.
Large organizations often use Single Sign-On (SSO) to allow employees to log in using their company identity providers, such as Microsoft Entra ID (Azure AD), Okta, or Google Workspace.
This simplifies user management while improving security and enforcing organizational policies.
Best for: Enterprise environments.v
A Personal Access Token (PAT) is a secure authentication credential used instead of your GitLab account password for Git operations over HTTPS.
Earlier, users could clone, push, and pull repositories using their GitLab username and password. However, this method was less secure and increased the risk of credential exposure.
To improve security, GitLab now recommends using a Personal Access Token (PAT) for HTTPS authentication instead of your account password.
Think of a PAT as a temporary password that is generated specifically for Git operations. Unlike your account password, a PAT can be limited to specific permissions and revoked at any time without affecting your account login.
Using a PAT provides several security benefits:
Secure alternative to account passwords.
Can be revoked anytime without changing your account password.
Permissions can be restricted using scopes.
Commonly used for Git over HTTPS and API access.
Reduces the risk of exposing your actual login credentials.
A Personal Access Token is commonly used when:
Cloning a repository over HTTPS.
Pushing code to GitLab.
Pulling the latest changes.
Accessing the GitLab REST API.
Integrating GitLab with third-party tools.
An SSH Key is one of the most secure and recommended ways to authenticate with GitLab. Instead of entering your username and password every time you interact with a repository, SSH uses a public-private key pair to verify your identity.
Once your SSH key is configured, you can clone, pull, and push code securely without repeatedly entering your credentials.
This is why most DevOps Engineers and software developers prefer SSH authentication for their daily workflow.
SSH authentication works using two keys:
Private Key โ Stored securely on your local machine. Never share this key with anyone.
Public Key โ Uploaded to your GitLab account so GitLab can verify your identity.
When you connect to GitLab, it verifies your private key against the stored public key. If they match, access is granted without asking for your password.
SSH authentication offers several advantages over password-based authentication:
More secure than passwords
No need to enter credentials repeatedly
Faster Git operations
Ideal for developers and DevOps engineers
Widely used in production environments
Setting up SSH authentication involves four simple steps:
Run the following command on your local machine or server.
ssh-keygen
This command generates both the private key and the public key.
Display the public key using:
cat ~/.ssh/id_rsa.pub
Copy the entire output.
After adding your SSH key, copy the repository's SSH URL.
Example:
git@gitlab.com:group-name/project-name.git
Now clone the repository:
git clone git@gitlab.com:group-name/project-name.git
Once configured, Git will authenticate automatically using your SSH key.
Single Sign-On (SSO) is an authentication method that allows users to access GitLab using their organization's existing identity provider instead of creating and managing a separate GitLab password.
In most enterprise environments, employees already have company accounts managed by services such as Microsoft Entra ID (Azure AD), Okta, Google Workspace, or other identity providers. With SSO, users can sign in to GitLab using these existing accounts, making authentication both secure and convenient.
Instead of remembering multiple usernames and passwords for different applications, users authenticate once through their organization's identity provider and gain access to GitLab based on the permissions assigned by the organization.
When a user attempts to log in to GitLab, they are redirected to the organization's identity provider. After successful authentication, the identity provider securely verifies the user's identity and grants access to GitLab.
Organizations prefer SSO because it improves both security and user management.
Some key benefits include:
Users log in with their company credentials.
No need to remember multiple passwords.
Centralized user and permission management.
Improved security through Multi-Factor Authentication (MFA).
Faster onboarding and offboarding of employees.
Reduced risk of unauthorized access.
SSO is primarily used in large organizations and enterprises where hundreds or even thousands of employees need secure access to GitLab.
Some common use cases include:
Large software companies
Banking and financial institutions
Government organizations
Healthcare companies
Enterprises with centralized identity management
Congratulations! ๐ You have successfully completed Day 2 of the GitLab learning series.
In this chapter, you learned how GitLab organizes repositories using Groups and Projects, explored different authentication methods, and configured secure access from an AWS EC2 instance.
Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.
I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.
๐ง Email: gujjarapurv181@gmail.com
๐ Portfolio: https://www.apurv-gujjar.co.in
๐ GitHub: https://github.com/ApurvGujjar07
๐ผ LinkedIn: https://www.linkedin.com/in/apurv-gujjar
If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.