# Day 2: GitLab Projects, Groups & Secure Authentication

### Organizing Projects and Accessing GitLab Repositories Securely

> 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).

## 📖 Introduction

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.

## 🎯 What You'll Learn

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
    

## 📚 Prerequisites

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)
    

## 👥 What are GitLab Groups?

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/68a09e3f-8cd2-46e0-bf88-193c053cb03a.png align="center")

## Example

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/bf487fda-c84a-4c31-ab5e-71d4c0f287eb.png align="center")

## Why Use Groups?

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.

## 📁 What are GitLab Projects?

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.

## Example

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/f5cf6059-7695-4520-a1d2-de435117a6b9.png align="center")

## Why Use Projects?

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**.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/491d9d70-d477-4758-a084-fc59cc4de792.png align="center")

## 🔄 Groups vs Projects

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/b854750f-22a6-4125-b13c-56d5ec946588.png align="center")

## 🎯 When Should You Use a 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.
    

## 🎯 When Should You Use a Project?

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.
    

## 🔐 Git Authentication in GitLab

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/2721b37a-fdc9-4e5c-9300-8f58ad04227e.png align="center")

## 🔑 Authentication Methods in GitLab

GitLab provides three primary authentication methods:

### 1️⃣ SSH Keys

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.

### 2️⃣ Personal Access Token (PAT)

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.

### 3️⃣ Single Sign-On (SSO)

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

## 🎫 Personal Access Token (PAT)

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/a3065e95-6d6d-4b6b-b60f-3762f15c25d5.png align="center")

## 📌 Why Use a Personal Access Token?

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.
    

## 📍 Where Can You Create a PAT?

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/5edb7a50-44c9-40c5-9a6d-f980e9b53113.png align="center")

## 🔧 Common Use Cases

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.
    

## 🔑 SSH Keys

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/408153ee-955f-44fd-bfe5-57b5372d8029.png align="center")

## 🔍 How SSH Authentication Works

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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/438a375a-2560-4647-9595-aaa5ce87d9c6.png align="center")

## 🚀 Why Use SSH Keys?

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
    

## 🛠️ Basic SSH Setup

Setting up SSH authentication involves four simple steps:

### Step 1: Generate an SSH Key Pair

Run the following command on your local machine or server.

```shell
ssh-keygen
```

This command generates both the **private key** and the **public key**.

### Step 2: View the Public Key

Display the public key using:

```shell
cat ~/.ssh/id_rsa.pub
```

Copy the entire output.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/1b462509-da58-4152-8612-e0d1d342fa4b.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/f7ad2414-d767-4f29-8232-106bad47816e.png align="center")

### Step 4: Clone the Repository Using SSH

After adding your SSH key, copy the repository's **SSH URL**.

Example:

```shell
git@gitlab.com:group-name/project-name.git
```

Now clone the repository:

```shell
git clone git@gitlab.com:group-name/project-name.git
```

Once configured, Git will authenticate automatically using your SSH key.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/bc2ef218-3bf4-4a27-b40f-23859ea53c39.png align="center")

## 🏢 Single Sign-On (SSO)

**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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/f5fc1c81-c8e9-4d89-a074-7727a46cf686.png align="center")

## **🔍 How SSO Works**

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/ef7bc45f-9750-4b74-b70d-542d64c73749.png align="center")

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.

## 🚀 Benefits of Using SSO

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.
    

## 🏢 Where is SSO Commonly Used?

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
    

## 🎯 Summary

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.

## **👨‍💻 About the Author**

**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.

## **📬 Connect With Me**

📧 **Email:** [**gujjarapurv181@gmail.com**](mailto:gujjarapurv181@gmail.com)

🌐 **Portfolio:** [**https://www.apurv-gujjar.co.in**](https://www.apurv-gujjar.co.in)

🐙 **GitHub:** [**https://github.com/ApurvGujjar07**](https://github.com/ApurvGujjar07)

💼 **LinkedIn:** [**https://www.linkedin.com/in/apurv-gujjar**](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.