如何在GitLab流水线中最佳使用Hashicorp Vault？

Question

假设我想要创建一个变量，其值来自Vault。

variables:
  $SSH_PRIVATE_KEY: `vault kv get -field=private_key project/production`
before_script:
  - echo "$SSH_PRIVATE_KEY"

这有可能吗？

在流水线中使用Vault秘密的另一种方式是否存在？

- Gregory

Answer 1

2019年7月原始回答:

你可以在之前/之后的脚本步骤中看到它的使用，最后会有一个已撤销的令牌。
以gitlab.eng.cleardata.com pub/pipelines/gcp-ci.yml为例：

# Obtains credentials via vault (the gitlab-runner authenticates to vault using its AWS credentials)
# Configures the `gcloud` sdk and `kubectl` to authenticate to our *production* cluster
#
# Note: Do not override the before_script or the after_script in your job
#
.auth-prod: &auth-prod
  image: cleardata/bionic
  before_script:
    - |
      export CLUSTER_NAME=production
      export CLUSTER_LOCATION=us-central1
      export CLUSTER_PROJECT_ID=cleardata-production-cluster
    - vault login -method=aws -path=gitlab-ci -no-print header_value=gitlab.eng.cleardata.com
    - GCP_CREDS=$(vault read -field=private_key_data gitlab-ci/gcp/cleardata-production-cluster/key/deployment-key)
    - gcloud auth activate-service-account --key-file=<(base64 -d <<<$GCP_CREDS)
    - gcloud auth configure-docker
    - gcloud beta container clusters get-credentials $CLUSTER_NAME --region $CLUSTER_LOCATION --project $CLUSTER_PROJECT_ID
  after_script:
    - vault token revoke -self

---

2020年3月更新：GitLab 12.9已支持此功能

HashiCorp Vault GitLab CI/CD 托管应用

GitLab希望为用户提供现代化的机密管理。现在，我们为用户提供了在Kubernetes集群中安装Vault作为GitLab CI托管应用程序流程的一部分的能力。
这将支持在Helm图表安装中在项目级别进行密钥、令牌和其他机密的安全管理。

请参阅文档和问题。

---

2020年4月：GitLab 12.10:

从HashiCorp Vault检索CI/CD机密

在此版本中，GitLab添加了对轻量级JSON Web Token（JWT）身份验证的支持，以与您现有的HashiCorp Vault集成。

现在，您可以通过利用HashiCorp的JWT身份验证方法，无缝地为CI/CD作业提供机密，而不必手动将机密作为变量提供给GitLab。

请参见文档和问题。

---

请查看GitLab 13.4（2020年9月）

仅适用于高级/银卡会员：

在CI作业中使用HashiCorp Vault的秘密

在GitLab 12.10中，GitLab引入了GitLab Runner获取和注入CI作业中的秘密的功能。现在，GitLab通过在.gitlab-ci.yml文件中构建一个新的secrets语法来扩展JWT Vault身份验证方法。这使您更容易配置和使用HashiCorp Vault与GitLab。

https://about.gitlab.com/images/13_4/vault_ci.png -- 在CI作业中使用HashiCorp Vault的秘密

请参见文档和问题。

---

查看 GitLab 13.9（2021年2月）

Vault JWT（JSON Web Token）支持GitLab环境。

为了简化与HashiCorp Vault的集成，我们推出了Vault JWT令牌支持。从发布开始，您可以基于JWT中的数据限制访问权限。此版本为限制凭据的访问权限提供了一个新的维度：作业所针对的环境。

此版本扩展了现有的Vault JWT令牌，以支持基于环境的限制。由于用户运行流水线时可以提供“环境”名称，因此我们建议您将新的基于环境的限制与已存在的ref_type值一起使用，以获得最大安全性。

请参阅文档和问题。

- VonC

Answer 2

我们的构建器镜像中内置了一个助手脚本，可以将指向密钥的GitLab CI/CD作业变量转换为包含Vault密钥的作业环境变量。在我们的情况下，我们还使用appRole身份验证方法来限制临时Vault访问令牌的有效性。

一个示例用例是：

I want a job env var "MY_SECRET_TOKEN" with a value from a Vault secret.
So I add a CI/CD variable called V_MY_SECRET_TOKEN="secret/<path>/<key>"
Then I insert a job step to retrieve the secret value and populate
  the MY_SECRET_TOKEN with the value associated with the key.

在GitLab中设置的CICD作业中添加的变量。

VAULT_ADDR=https://vault.example.com:8200
VAULT_ROLE_ID=db02de05-fa39-4855-059b-67221c5c2f63
VAULT_SECRET_ID=6a174c20-f6de-a53c-74d2-6018fcceff64
VAULT_VAR_FILE=/var/tmp/vault-vars.sh

在 .gitlab-ci.yml 作业定义中添加了步骤。

script:
  - get-vault-secrets-by-approle > ${VAULT_VAR_FILE}
  - source ${VAULT_VAR_FILE} && rm ${VAULT_VAR_FILE}

这里是我们使用的get-vault-secrets-by-approle帮助脚本的参考。这里是设计背后的思考的说明。

'before_script'选项不适合我们的工作流程，因为我们在gitlab-ci.yml定义中定义了特权和非特权阶段的组合。非特权作业构建和QA代码，而特权作业则打包和发布代码。VAULT_ROLE_ID和VAULT_SECRET_ID作业变量只应该对特权打包和发布作业可见。

我还尝试使用include、extend和yaml锚点，但我想将项目合并到现有的yaml映射(script: {}或before_script: {})中，而不是用模板替换映射中的所有项目。

- Chris Ottinger