GitLab：GitLab安全加固
发布时间:2026-04-22 12:01
GitLab安全加固实战手册
一、前言
搞过的人都知道，GitLab装完默认配置就是个大坑——弱密码随便过、API端口全开放、敏感数据明文传输，稍微被扫到就是一场灾难。今天把10年踩过的坑攒成这份手册，照着做，30分钟让GitLab从裸奔变成正经的生产级防护。
二、操作步骤
第1步：强制HTTPS，踢掉HTTP明文流量
CentOS/RHEL 路径：
/etc/gitlab/gitlab.rb
Ubuntu 路径：
/etc/gitlab/gitlab.rb
执行命令：
sudo vi /etc/gitlab/gitlab.rb
# 添加或修改以下配置：
external_url 'https://gitlab.yourdomain.com'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/privkey.pem"
sudo gitlab-ctl reconfigure
预期输出：
gitlab Reconfigured!
run: nginx: (pid 12345) 1s; run: log: (pid 6789) 1s
第2步：关闭注册，禁止anyone进来薅羊毛
执行命令：
sudo gitlab-rails console
# 进入rails console后执行：
u = User.where(admin: true).first
u.sign_in_count
预期输出：
GitLab Enterprise Edition 16.3.0-ee (REV...)
Loading production database... done
irb(main):001:0>
继续执行：
ApplicationSetting.last.update(
signup_enabled: false,
password_authentication_enabled_for_web: true,
password_authentication_enabled_for_git: true
)
预期输出：
=> true
然后编辑gitlab.rb：
gitlab_rails['gitlab_signup_enabled'] = false
gitlab_rails['require_admin_password_after_authentication'] = true
sudo gitlab-ctl reconfigure
第3步：密码策略——至少8位，大小写数字全得要
执行命令：
sudo gitlab-rails console
ApplicationSetting.last.update(
password_required_regex: '(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}',
minimum_password_length: 12
)
预期输出：
=> true
=> #<ApplicationSetting id:1 ...>
加到gitlab.rb永久生效：
gitlab_rails['password_min_length'] = 12
gitlab_rails['password_requires_character'] = true
gitlab_rails['password_requires_number'] = true
gitlab_rails['password_requires_lowercase'] = true
gitlab_rails['password_requires_uppercase'] = true
sudo gitlab-ctl reconfigure
第4步：限制IP访问，只让公司出口进来
执行命令：
sudo vi /etc/gitlab/gitlab.rb
添加配置：
gitlab_workhorse['auth_backend'] = "127.0.0.1:8181"
nginx['allow_connect_src'] = ["192.168.1.0/24", "10.0.0.0/8"]
gitlab_rails['trusted_proxies'] = ['10.0.0.1', '10.0.0.2']
也可以在Admin Area设置白名单：
# 访问 Admin Area -> Settings -> Network -> IP whitelist
# 添加受信任的IP段
10.0.0.0/8
192.168.0.0/16
sudo gitlab-ctl reconfigure
预期输出：
nginx: the configuration file /var/opt/gitlab/nginx/conf/gitlab-http.conf syntax is ok
nginx: configuration file test is successful
run: nginx: (pid 12345) 1s; run: log: (pid 6789) 1s
第5步：开启两因素认证，密码被撞库也不怕
执行命令：
# 启用Two-factor认证
sudo gitlab-rails console
Feature.enable(:two_factor_authentication)
ApplicationSetting.last.update(two_factor_grace_period: 168)
预期输出：
=> true
=> 168 # 7天宽限期
强制所有管理员开启：
sudo gitlab-rake gitlab:two_factor:enable_for_all_users
预期输出：
Enabling two-factor authentication for all users...
Done.
加到配置文件：
gitlab_rails['omniauth_allow_bypass_two_factor'] = false
gitlab_rails['require_tfa'] = true
sudo gitlab-ctl reconfigure
第6步：禁止内网部署绕过，改掉默认端口
警告：修改SSH端口前，确保你的客户端已更新配置，否则可能导致无法连接！
执行命令：
sudo vi /etc/gitlab/gitlab.rb
# 添加SSH端口配置
gitlab_rails['gitlab_shell_ssh_port'] = 2222
修改SSH服务端口：
# CentOS/RHEL
sudo vi /etc/ssh/sshd_config
# Port 22 改为 Port 2222
sudo systemctl restart sshd
修改GitLab nginx暴露端口：
nginx['listen_port'] = 80
nginx['listen_https'] = false
Ubuntu 操作：
# Ubuntu
sudo vi /etc/ssh/sshd_config
# Port 22 改为 Port 2222
sudo systemctl restart ssh
sudo gitlab-ctl reconfigure
预期输出：
gitlab Reconfigured!
run: gitaly: (pid 11111) 1s
run: gitlab-workhorse: (pid 22222) 1s
run: nginx: (pid 33333) 1s
第7步：审计日志，出了事能追溯到谁干的
执行命令：
sudo gitlab-rails console
# 开启审计功能
Feature.enable(:audit_events)
Logster::Store.enable!
预期输出：
=> true
=> #<Logster::Store...>
查看审计日志：
sudo gitlab-rake gitlab:audit:log --trace
预期输出：
** Invoke gitlab:audit:log (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute gitlab:audit:log
导出审计日志：
# 查看最近的用户活动
sudo gitlab-rails runner "AuditEvent.where(event_type: 'session_ended').limit(100).each { |e| puts \"#{e.created_at} - #{e.author.name}\" }"
预期输出：
2024-01-15 14:23:11 - zhangsan
2024-01-15 14:18:45 - lisi
2024-01-15 13:55:32 - wangwu
三、常见问题FAQ
Q：强制HTTPS后内部网络无法访问，怎么处理？
A：这说明你网络规划有问题。先在gitlab.rb里把external_url改成https://内网IP:8443，然后让内网客户端通过8443访问，外部用户走443。配置示例：nginx['listen_port'] = 8443，nginx['listen_https'] = true。生产环境建议用nginx反向代理到GitLab，别让GitLab直接暴露。
Q：修改了密码策略，老用户登录时被要求改密码，怎么批量处理？
A：不要慌，这是正常行为。密码策略对已存在用户立即生效。用户点击"忘记密码"重置即可，或者你用管理员账号去Admin Area -> Users -> 选中用户 -> Send password reset link。如果团队规模大，用API批量触发：curl --request POST --header "PRIVATE-TOKEN: YOUR_TOKEN" "https://gitlab.example.com/api/v4/users/:id/reset_password"
Q：开启两因素认证后管理员手机丢了登录不上，怎么办？
A：备份recovery codes。登录服务器执行：sudo gitlab-rails console，然后User.find_by(email: 'admin@example.com').generate_otp_backup_codes!，用backup codes登录后重新配置2FA。预防措施：每次开启2FA后第一时间下载recovery codes保存到安全的地方。
Q：IP白名单设置后CI/CD流水线失败，怎么排查？
A：GitLab Runner通常在内网，需要把Runner的IP加入白名单。查看Runner的IP：sudo gitlab-runner status，然后在白名单里添加。CI/CD的job执行时是Runner在访问GitLab，不是开发者的电脑，所以CI失败很可能是Runner IP不在白名单里。
Q：加固完成后如何验证安全性？
A：跑一遍这些检查项。curl -I http://YOUR_GITLAB_URL - 检查是否301跳转到https；用nmap扫描端口看还有哪些暴露；用弱密码字典测试登录接口；检查Logs里有没有异常的登录尝试；登录Web UI查看Settings里各项配置是否符合预期。
四、总结
GitLab安全加固核心就三件事：HTTPS加密传输、访问控制收紧、审计追溯能力。这7步做下来，基础防护就算到位了。关键配置优先级：强制HTTPS > 密码策略 > IP白名单 > 两因素认证 > 审计日志 > SSH端口修改。做完这些别忘了定期更新GitLab版本，漏洞修复也是安全的一部分。
延伸阅读：
- GitLab官方安全文档：https://docs.gitlab.com/ee/security/
- OWASP加固指南：https://cheatsheetseries.owasp.org/
- GitLab安全加固Checklist：https://about.gitlab.com/blog/2023/01/30/gitlab-security-best-practices/
记住：安全加固不是一次性的事，定期review配置、关注官方CVE、及时更新版本，才是长期安全之道。