在 Cloudflare Zero Trust 之下自托管 GitLab（实用 DevOps 实验）

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 前端，强制基于身份的访问控制。

为什么这很重要

即使这只是一个实验：

• 架构映射了真实企业的部署
• 零信任概念得到正确应用
• 中途无需重新设计基础设施

最重要的是，系统是增量演进的。

经验教训

• 反向代理是基础
• 身份验证胜过基于 IP 的安全
• 免费层足以学习真实概念
• 分阶段设计能降低错误

接下来可以做什么

本实验可以向多个方向扩展：

• 使用 Cloudflare Tunnel 替代暴露端口
• 仅通过 HTTPS 进行 Git 操作
• 添加 GitLab Runner
• 基础设施即代码（IaC）
• 迁移到 KVM 或 Proxmox

仓库

完整实验——包括 Vagrant 配置、供应脚本以及逐步文档——可在此获取：

👉

该仓库旨在配合文章阅读：文章解释为什么每一层存在，仓库展示如何实现。

最后思考

该项目展示了零信任不是一种产品——它是一种设计方法。

通过从简单开始并有意层叠安全，即使是小型家庭实验室也能教授可扩展到真实系统的模式。