本文内容均来自个人笔记并重新梳理,如有错误欢迎指正!
如果对您有帮助,烦请点赞、关注、转发、订阅专栏!
专栏订阅入口
| 精选文章 | Kubernetes | Docker | Linux | 羊毛资源 | 工具推荐 |
往期精彩文章
【Docker】(全网首发)Kylin V10 下 MySQL 容器内存占用异常的解决方法
目录
一、背景介绍
近期公司研发侧开始反馈,从公司内部自建的 GitLab 服务拉取代码时频繁出现 403 错误,提示信息大致如下:
Too many failed authentication attempts from this IP
fatal: unable to access 'https://gitlab.xx.com/xxx/xxx.git/': The requested URL returned error: 403
经过排查定位到是 GitLab 服务的 RACK ATTACK 模块对访问 IP 进行了限制。公司的 GitLab 服务之前有负载均衡设备,因此所有对 GitLab 服务发起的相关请求,其对应的 IP 均被 GitLab 服务认定为负载均衡设备的 IP,从而造成单个 IP 频繁请求 GitLab 服务触发了服务的安全限制。
本文将详细介绍解决该问题的相关过程,GitLab 服务相关信息如下:
- 版本信息:GitLab CE 17.4.2
- 部署组件:GitLab、PostgreSQL、Redis
- 部署方式:Kubernetes 环境下,部署为 StatefulSet 对象(后续找时间出部署教程)
- 镜像名称:sameersbn/gitlab:17.4.2
二、过程介绍
1、临时解决方法
单个 IP 频繁请求 GitLab 服务、触发 RACK ATTACK 模块的安全限制后,GitLab 服务会向 Redis 服务的库中写入一个 key,格式如下。可以通过前缀查询并删除该 key 的方式,临时解除 IP 封禁。
cache:gitlab:rack::attack:allow2ban:ban:xx.xx.xx.xx
但是后续请求很可能在短时间内再次触发安全限制导致 IP 被封禁,需要保持关注并及时操作解禁,在日常工作中不太友好。因此需要考虑通过其他方式解决问题,解决思路调整为通过修改 GitLab 服务配置来实现 RACK ATTACK 模块的禁用。
2、官方文档方法
GitLab 官方文档中介绍了 RACK ATTACK 模块的认证配置,文档地址如下:
https://archives.docs.gitlab.com/17.11/omnibus/settings/configuration/#configuring-rack-attack
但是实际操作发现,GitLab 服务的容器中并不存在 /etc/gitlab/gitlab.rb 文件(可能是 GitLab 版本或 Docker 镜像原因导致)
3、修改配置文件
说明:由于 GitLab 服务采用了 Kubernetes 环境下的容器化部署方式,相关配置文件无法直接在容器后修改生效,因此需要将文件内容进行修改后,以 ConfigMap 方式挂载到相应位置。
- /home/git/gitlab/config/gitlab.yml
- 将 gitlab.yml 文件内容中 rack_attack.git_basic_auth.enabled 改为 false
- 文件挂载后 Pod 启动失败,经排查 gitlab.yml 文件是动态生成的,无法提前进行挂载
- /home/git/gitlab/config/gitlab.yml.example
- 看起来 gitlab.yml 文件生成自 gitlab.yml.example 文件,转为修改 gitlab.yml.example 文件内容
- 文件挂载后 Pod 启动成功,但 gitlab.yml 文件中的 rack_attack.git_basic_auth.enabled 仍为 true
- /home/git/gitlab/config/initializers/1_settings.rb 及其他相关文件
- 文件挂载后 Pod 启动成功,但 gitlab.yml 文件中的 rack_attack.git_basic_auth.enabled 仍为 true
修改配置文件方式均不生效,需要进一步调整思路。
4、从 entrypoint 入手分析
- 查看 GitLab 服务的镜像层信息,获取 entrypoint 文件路径
- 查看 /sbin/entrypoint.sh 文件内容
- 查看 functions 文件内容,得知存在一个 RACK_ATTACK_ENABLED 变量控制 RACK ATTACK 的启停
- 查看 env-defaults 文件内容,进一步确认 RACK_ATTACK_ENABLED 变量来自于全局环境变量,如果没有全局环境变量不存在,则 RACK_ATTACK_ENABLED 默认取值为 true,即 RACK ATTACK 模块默认启用(官方宣传较新版本默认禁用,和实际不一致)
5、最终解决方法
经过以上分析可知,我们有两种方式可以解决本文开头的问题:
- 通过定义环境变量的方式,将 RACK_ATTACK_ENABLED 设置为 false 以禁用 RACK ATTACK 模块
- 通过定义环境变量的方式,将 RACK_ATTACK_ENABLED 设置为 true 以启用 RACK ATTACK 模块,同时通过 RACK_ATTACK_WHITELIST 变量设置 IP 白名单,添加负载均衡设备的 IP 地址
最终我们选择直接禁用 RACK ATTACK 模块即可:
kubectl edit sts gitlab
...
# 添加环境变量
env:
...
- name: RACK_ATTACK_ENABLED
value: "false"
...
验证结果: