GitLab 네트워크 정책¶

GitLab 서비스의 네트워크 흐름 정책을 정의함. 운영 환경에서는 Reverse Proxy 구조와 내부 네트워크 구조를 모두 고려하여 접근 정책을 설계해야 함.

GitLab 서비스는 외부 인터넷에 직접 노출하지 않으며, Private Network 환경 + Reverse Proxy 기반 구조로만 운영함을 전제로 함.

1. 개요¶

GitLab 서비스는 다음 두 가지 트래픽을 분리하여 처리함. - Web 서비스 (HTTP/HTTPS) - Git 데이터 전송 (SSH)

각 트래픽은 서로 다른 포트를 사용하며, 보안 및 운영 관리를 위해 분리하여 구성함.

GitLab 설치 방식은 다음 두 가지로 구분함.

단일 서버 구성 (Nginx와 GitLab이 같은 서버)
- Reverse Proxy(Nginx) 와 GitLab을 동일 서버에서 운영하는 구조
분리 구성 (Nginx: 192.168.0.154, GitLab: 192.168.0.100)
- Gateway(Nginx) 와 GitLab을 서로 다른 서버에 분리하여 운영하는 구조
- GitLab Web Service 를 반드시 내부 포트(8081)로만 전달함. ex) proxy_pass http://192.168.0.100:8081;

각 포트는 다음과 같이 역할을 명확히 분리함.

HTTP/S Port: 80 / 443
- Internal Entry Point
- Reverse Proxy(Nginx) 에서 사용
- 사내 사용자 요청 수신 (내부망 또는 VPN)
GitLab Web Service Port: 8081
- GitLab Web Service
- Nginx 와의 내부 통신용
- 외부 접근 차단
- Loopback 또는 내부 Reverse Proxy(Nginx) 에서만 접근 허용
GitLab SSH Port: 2222
- GitLab SSH
- Git clone / push / pull 용
- 외부 접근 차단
- 내부망 또는 VPN 사용자만 접근 허용

Reverse Proxy 환경에서 포트 충돌을 방지하고, 역할 분리를 명확히 하기 위해 다음과 같이 정의함.

설명:

구분	포트	서비스	비고
내부 전용	80 / 443	Web Proxy	Nginx Gateway (사내 사용자 접근)
관리용	22	OS SSH	관리자 접근용 (특정 IP 필수 제한)
내부 전용	`8081`	GitLab Web	GitLab Web UI (Reverse Proxy 내부 통신용)
내부 전용	`2222`	GitLab SSH	Git clone / push / pull (사내망 또는 VPN 전용)

GitLab 과 Nginx 가 동일 서버에 존재하는 경우 다음과 같이 동작함.

Client(Internal/VPN) → 80/443 → Nginx → Loopback 127.0.0.1:8081 → GitLab Web
Client(Internal/VPN) → 2222 → GitLab SSH

특징: - 8081 은 Loopback(127.0.0.1) 으로만 접근 허용함

GitLab 이 내부 서버(예: 192.168.x.x)에 설치된 경우 다음과 같이 동작함.

Client(Internal/VPN) → 80/443 → Nginx → Internal 192.168.x.x:8081 → GitLab Web
Client(Internal/VPN) → 2222 → Internal 192.168.x.x:2222 → GitLab SSH

특징: - 8081 은 Reverse Proxy 또는 Gateway 에서만 접근 허용함