AWS EC2上GitLab CI Runner需开放的防火墙端口配置

首先明确核心逻辑：GitLab CI Runner默认采用主动轮询模式和GitLab服务端通信，全程由Runner主动向GitLab发起请求拉取任务、回传日志/产物，不存在GitLab服务端主动连接Runner的入站流量，因此你不需要开放多余入站端口。

必须保留的入站规则 #

• 仅放通TCP 22端口（SSH），源地址严格限制为你自己的运维固定IP/信任的办公网段，绝对不要对0.0.0.0/0开放SSH。
• 除SSH外，Runner正常运行不需要任何其他入站端口，你之前配置的全量入站规则完全没有必要，属于高危配置。

仅开SSH就无法运行的根因 #

问题出在出站规则配置错误，不是入站开少了。你需要配置的是对应出站放通规则，而非增加入站端口：

• 放通到你的GitLab实例（自建GitLab/GitLab.com均可）的TCP 443端口（如果你的GitLab用HTTP访问就放通80端口），目标地址直接绑定GitLab实例的IP/对应安全组，不要对全网开放。
• 按需放通CI任务依赖的公网/内网资源出站权限：比如拉取Docker镜像、pip/npm依赖包、连接私有代码仓库等场景，按实际访问的目标地址放通对应端口（比如拉公网镜像走443、拉私有Git仓库走22），不需要的出站权限全部拒绝，进一步收敛攻击面。

特殊场景说明 #

• 如果你启用了GitLab CI的交互式Web终端功能，也不需要额外开入站端口，该功能依赖Runner主动和GitLab建立的WebSocket长连接通信，入站侧无额外需求。
• 如果你使用Docker Machine/EC2自动扩缩容的Runner executor，仅需要放通Runner管理节点到临时Worker节点的TCP 22出站权限即可，不需要给管理节点开额外入站端口。
• 如果你临时需要从外部访问Runner上运行的调试服务，调试期间临时开放对应端口、源地址限你自己的IP即可，调试完成立刻关闭规则。

安全组配置核心原则：所有入站流量默认拒绝，仅开放明确需要的端口且严格限制源地址；出站流量按需放通，不做无意义的全量放行。

内容的提问来源于stack exchange，提问作者Arnold Zahrneinder