您可以改用Google Secret Manager。我们仍在更新文档,但是有一个示例如何将其与Cloud Build一起使用:
首先,创建一个秘密:
$ echo -n "my-secret-data" | gcloud beta secrets create "my-api-key" \
--replication-policy "automatic" \
--data-file -
授予Cloud Build Service帐户访问您的机密的权限:
$ gcloud beta secrets add-iam-policy-binding "my-api-key" \
--member "serviceAccount:<project-number>@cloudbuild.gserviceaccount.com" \
--role "roles/secretmanager.secretAccessor"
然后在构建步骤中检索秘密:
steps:
- name: 'gcr.io/cloud-builders/gcloud@sha256:c1dfa4702cae9416b28c45c9dcb7d48102043578d80bfdca57488f6179c2211b'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud beta secrets versions access --secret=my-api-key latest > /secrets/my-api-key
volumes:
- name: 'secrets'
path: '/secrets'
- name: 'my-step'
volumes:
- name: 'secrets'
path: '/secrets'
args: # ... /secrets/my-api-key contains the secret
我应该如何在我的步骤的容器中指定env变量?
关于多个秘密,我必须一次获取一个秘密吗?为什么不在Secret Manager中自动替换值?在哪里可以提出功能请求?
您可以多次运行该gcloud命令(每个命令都放在自己的行上)。提出了更深入的Cloud Build集成功能请求。
嗨,塞思,热爱GSM的工作,谢谢!关于上述内容,是否存在/ secrets卷中的机密为纯文本的安全性担忧?如果与Kaniko一起使用层缓存怎么办?
这绝对是一个问题,也是我们提倡让应用程序直接与SM对话或直接存储在envvar中的原因之一。fs是当今最可用的便携式解决方案,但我们一直在努力进行产品改进