如何将Jira Cloud与VPN后方的自托管Gitlab完成集成

以下方案按安全性、实现难度从优到劣排序，优先推荐第一种

方案1：出站单向推送集成（最低侵入性，无需暴露Gitlab入站端口） #

• 实现逻辑：Jira Cloud原生集成能力支持内网Gitlab主动向Jira Cloud推送事件，不需要Jira侧主动访问Gitlab，完全符合内网安全规则
• 配置步骤：
  1. 确认内网Gitlab服务器已开放公网出站权限，允许访问Jira Cloud的域名范围：*.atlassian.net、*.jira.com，不需要开放任何入站端口
  2. 在Jira Cloud后台进入「设置→应用→DVCS账户→添加账户」，选择Gitlab类型，生成对应的客户端ID、密钥
  3. 登录内网Gitlab管理后台，进入「集成→Jira」配置页，填入Jira Cloud站点地址、刚才生成的OAuth凭据、具备对应权限的Jira账号API令牌
  4. 按需开启触发规则：提交信息带Jira Issue编号自动关联、合并请求状态同步到Jira Issue、流水线运行状态同步等，所有事件均由Gitlab主动推送到Jira Cloud的公网端点
• 适用场景：覆盖90%以上的常规集成需求，Jira侧点击Gitlab关联链接时，只需要访问用户的设备已连VPN即可跳转，不需要Jira服务器访问内网Gitlab

方案2：反向代理/隧道暴露受控的Gitlab入站访问 #

如果你的场景需要Jira Cloud主动拉取Gitlab内容（比如拉取代码片段、主动扫描提交记录等），可以选择仅给Jira开放受控的访问权限，不对外暴露Gitlab

• 实现逻辑：在公网部署反向代理或隧道服务，仅放行Jira Cloud官方公布的IP段的访问请求，转发到内网Gitlab服务
• 配置步骤：
  1. 从Atlassian官方文档获取Jira Cloud的公网IP段，在防火墙/反向代理上配置严格的IP白名单，只允许这些IP访问Gitlab代理端口
  2. 可选的隧道/代理实现：
     • 在公网DMZ区部署Nginx反向代理，后端通过内网专线/IPsec VPN连接内部Gitlab服务器
     • 用frp、Cloudflare Tunnel等内网穿透工具，仅暴露Gitlab的443端口，同步配置IP白名单
  3. 为代理服务配置独立的域名和HTTPS证书，不要使用内网Gitlab的原有域名
  4. 在Jira Cloud的DVCS配置中填入代理域名作为Gitlab地址，完成集成
• 注意事项：必须严格限制代理服务的可访问路径，只开放Jira集成需要的API路径，禁止暴露管理员接口、用户注册接口等高风险路径

方案3：中间件双向同步 #

如果不想改动现有Gitlab和网络架构，可以用中间同步服务实现双向事件同步

• 实现逻辑：中间服务部署在内网环境，同时具备内网Gitlab访问权限和公网出站访问Jira Cloud的权限，负责两边的事件拉取、同步
• 配置步骤：
  1. 在内网部署轻量同步服务，可使用开源工具，也可以用简单的自研脚本实现
  2. 为服务配置Gitlab私有令牌和Jira Cloud API令牌
  3. 按需配置同步规则：监听Gitlab Webhook事件推送到Jira、定时拉取Jira Issue变更同步到Gitlab对应合并请求备注等
• 适用场景：自定义集成需求多、不想改动现有基础架构的场景

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