【K8s】GitLab 禁用 RACK ATTACK 机制

实施运维知识交流

专注于运维、实施交付领域，持续分享个人笔记、学习心得，欢迎关注，共同交流、成长！

84篇原创内容

公众号

背景介绍

近期公司研发侧开始反馈，从公司内部自建的 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"
...

验证结果：

图片

书籍推荐

最后推荐一本笔者从 Docker 进阶到 Kubernetes 自学过程中，受益较深的书籍。笔者经常复读，并结合工作实践不断加深理解和体会，可谓常读常新。