如何让GitLab CI/CD作业访问私有HashiCorp Vault以获取密钥?
GitLab.com共享运行器访问私有网络HCP Vault的配置方案
以下是三种可行的配置方案,可根据你的基础设施选型适配:
方案1:通过GitLab CI/CD隧道(GitLab Agent)访问
无需替换共享运行器,通过GitLab Agent作为桥梁,实现公网共享运行器作业对私有Vault的访问:
- 部署GitLab Agent到私有网络
- 进入GitLab项目的「设置 > CI/CD > 代理」,创建新代理,获取对应Kubernetes安装命令(或虚拟机部署脚本)。
- 在私有网络内的Kubernetes集群(或虚拟机)执行安装命令,确保Agent能正常访问Vault私有端点。
- 修改CI/CD配置
在.gitlab-ci.yml中指定通过Agent访问私有资源:fetch_secret: script: - vault kv get secret/app/credentials variables: VAULT_ADDR: "https://vault-private-endpoint:8200" agent: name: your-private-agent namespace: agent-namespace - 配置Vault认证
复用原有的JWT认证配置,确保Vault允许来自Agent的请求通过认证,并授予对应密钥的访问权限。
方案2:使用私有网络内的自我托管GitLab运行器
将运行器部署在可直接访问私有Vault的网络内,替代共享运行器:
- 部署自我托管运行器
- 从GitLab项目的「设置 > CI/CD > 运行器」获取注册令牌。
- 在私有网络内的虚拟机/K8s集群上执行注册命令:
gitlab-runner register --url https://gitlab.com/ --registration-token YOUR_TOKEN --executor docker --description "Private Network Runner" --tag-list "private-network" - 测试运行器与Vault私有端点的连通性,确保网络可达。
- 指定运行器标签
在CI/CD作业中通过标签调用私有运行器:fetch_secret: script: - vault kv get secret/app/credentials tags: - private-network variables: VAULT_ADDR: "https://vault-private-endpoint:8200"
方案3:通过SSH隧道转发流量(临时场景适用)
利用堡垒机建立SSH隧道,将Vault端口转发到共享运行器的作业容器内:
- 配置堡垒机
在私有网络内部署一台堡垒机,允许公网SSH访问(建议限制IP到GitLab共享运行器IP段,采用密钥认证)。 - CI/CD作业中建立隧道
在.gitlab-ci.yml中添加隧道建立步骤:fetch_secret: before_script: - apt-get update && apt-get install -y openssh-client - mkdir -p ~/.ssh && echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa - ssh -o StrictHostKeyChecking=no -L 8200:vault-private-endpoint:8200 bastion-user@bastion-ip & - sleep 3 # 等待隧道稳定 script: - VAULT_ADDR=http://localhost:8200 vault kv get secret/app/credentials variables: SSH_PRIVATE_KEY: "$BASTION_SSH_KEY" # 从GitLab项目CI/CD变量导入,设为掩码/保护变量
方案对比
- 方案1:无需维护运行器,适合长期稳定使用,依赖K8s或虚拟机部署Agent。
- 方案2:性能最优,无额外转发开销,需自行维护运行器。
- 方案3:快速上手,适合临时测试,安全性相对较低,需严格限制堡垒机权限。
内容的提问来源于stack exchange,提问作者TheBird956
相关产品推荐
相关产品推荐

