Cloudflare Zero Trust 뒤에서 GitLab 자체 호스팅 (실용적인 DevOps Lab)

Source: Dev.to

목표

GitLab Community Edition을 실제 인프라 환경을 반영하면서도 안전하고, 가시적이며, 되돌릴 수 있는 방식으로 배포하는 것이 목표였습니다.

이 실습은 다음에 초점을 맞춥니다:

• 개인 가상 머신에 GitLab 호스팅
• 단계적으로 인터넷에 노출
• 암묵적인 신뢰를 점진적으로 감소
• 무료 또는 커뮤니티‑티어 도구만 사용

시나리오

GitLab을 직접 호스팅하는 것은 어렵지 않습니다.
책임감 있게 호스팅하는 것이 어렵습니다.

GitLab을 직접 인터넷에 노출하면 스캐너, 무차별 로그인 시도, 불필요한 위험에 노출됩니다. 완전 잠금 설계부터 시작하는 대신, 이 실습에서는 GitLab을 점진적으로 노출하고, 보안 레이어를 이해하고 정당화될 때만 추가하는 방식을 탐구합니다.

초기 아이디어

GitLab을 직접 인터넷에 노출하는 대신 시스템을 계층화합니다:

• GitLab은 개인 VM에 존재
• 리버스 프록시가 퍼블릭 트래픽을 처리
• 최종적으로 Cloudflare가 게이트키퍼 역할을 수행

각 계층은 책임을 추가하고 — 위험을 감소시킵니다.

1단계 — 작동하게 만들기

우선 목표는 간단합니다: GitLab에 접근 가능하게 만들기.

GitLab은 퍼블릭 IP가 없는 VM 안에서 실행됩니다. 호스트 서버가 퍼블릭 주소를 가지고 있으며, Nginx를 통해 요청을 포워딩합니다.

이렇게 하면 이미 다음을 제공하게 됩니다:

• 격리
• 손쉬운 재구축
• 명확한 책임 분리

하지만 여전히 신뢰 기반 접근 방식입니다.

2단계 — 네트워크에 대한 신뢰 중단

GitLab이 정상 작동하면 보안이 초점이 됩니다.

“이 요청이 올바른 IP에서 온 건가?” 라고 묻는 대신, 시스템은 다음을 묻습니다:

이 사용자는 누구이며, 여기 있어야 하는가?

Cloudflare Zero Trust가 GitLab 앞에 위치해 신원 기반 접근을 강제합니다.

왜 중요한가

이 실습이지만:

• 아키텍처가 실제 기업 환경을 반영
• Zero Trust 개념이 올바르게 적용
• 중간에 인프라 재설계가 필요 없었음

가장 중요한 점은 시스템이 점진적으로 진화했다는 것입니다.

배운 점

• 리버스 프록시는 기본적인 요소
• 신원 확인이 IP 기반 보안보다 우수
• 무료 티어만으로도 실제 개념을 학습 가능
• 단계적 설계가 실수를 줄여줌

다음 단계

이 실습은 다양한 방향으로 확장할 수 있습니다:

• 노출 포트 대신 Cloudflare Tunnel 사용
• HTTPS 전용 Git 작업
• GitLab Runner 추가
• 인프라를 코드로 관리(IaC)
• KVM 또는 Proxmox로 마이그레이션

저장소

전체 실습 자료( Vagrant 설정, 프로비저닝 스크립트, 단계별 문서 포함)는 여기에서 확인할 수 있습니다:

👉

이 저장소는 기사와 함께 읽도록 설계되었습니다: 기사는 왜 각 레이어가 존재하는지를 설명하고, 저장소는 어떻게 구현되는지를 보여줍니다.

마무리 생각

이 프로젝트는 Zero Trust가 제품이 아니라 디자인 접근법임을 보여줍니다.

단순하게 시작하고 보안을 의도적으로 계층화함으로써, 작은 홈 랩이라도 실제 환경에 확장 가능한 패턴을 배울 수 있습니다.