是否有将Cloud Build中的环境变量注入App Engine Standard环境中的方法?
我不想将环境变量推送到app.yaml
或.env
内的GitHub上。因此,当Cloud Build拉并部署时,它会丢失.env
文件,并且服务器无法完成某些请求。
我试图避免使用数据存储,因为数据存储的异步特性会使代码更加混乱。我尝试使用发现的here加密机密,但是在我将这些机密添加到应用程序部署中并且它们没有进入部署后,这似乎不起作用,因此我认为这不是用于云构建。
我还尝试了教程here,以将.env
文件从存储设备导入App Engine Standard,但是由于Standard没有本地存储,因此我认为该文件无效。
因此,有没有将.env
注入App Engine标准环境而不使用数据存储区,也没有提交app.yaml
或.env
来更改控制权的情况?可能使用Cloud Build,KMS或某种类型的存储?
这是我为cloudbuild.yaml
做的尝试:
steps:
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]
secretEnv: ['SECRET1', 'SECRET2', 'SECRET3', 'SECRET4', 'SECRET5']
timeout: "1600s"
secrets:
- kmsKeyName: projects/<Project-Name>/locations/global/keyRings/<Key-Ring-Name>/cryptoKeys/<Key-Name>
secretEnv:
SECRET1: <encrypted-key-base64 here>
SECRET2: <encrypted-key-base64 here>
SECRET3: <encrypted-key-base64 here>
SECRET4: <encrypted-key-base64 here>
SECRET5: <encrypted-key-base64 here>
答案 0 :(得分:1)
这里是tutorial,介绍如何将环境变量安全地存储在云构建(触发器)设置中并将其导入到您的应用中。
基本上有三个步骤:
将环境变量添加到您的构建触发设置之一中的“变量”部分
Screenshot of where to add variables in build triggers
在构建触发器中设置的常规变量必须以下划线(_)开头
配置cloudbuild.yaml
(在代码示例的第二步)以从构建触发器中读取变量,将其设置为env vars,并将所有env vars写入本地.env文件中>
将couldbuild.yaml
(如下)添加到项目的根目录
steps:
- name: node:10.15.1
entrypoint: npm
args: ["install"]
- name: node:10.15.1
entrypoint: npm
args: ["run", "create-env"]
env:
- 'MY_SECRET_KEY=${_MY_SECRET_KEY}'
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]
timeout: "1600s"
将create-env
脚本添加到package.json
"scripts": {
"create-env": "printenv > .env"
},
从.env读取环境变量到您的应用程序(config.js)
安装dotenv软件包
npm i dotenv -S
向您的应用添加config.js
// Import all env vars from .env file
require('dotenv').config()
export const MY_SECRET_KEY = process.env.MY_SECRET_KEY
console.log(MY_SECRET_KEY) // => Hello
完成!现在,您可以通过触发云构建来部署应用程序,并且您的应用程序将可以访问环境变量。
答案 1 :(得分:1)
如果有人仍然对此感兴趣,我还有另一种解决方案。这应该适用于所有语言,因为环境变量直接添加到app.yaml
文件
在构建触发器中添加替换变量(如本answer中所述)。
将环境变量添加到app.yaml
中,以便可以用构建触发器变量轻松替换它们。像这样:
env_variables:
SECRET_KEY: %SECRET_KEY%
cloudbuild.yaml
中添加一个步骤,以将%XXX%
中的所有app.yaml
变量替换为生成触发器中的值。 - name: 'gcr.io/cloud-builders/gcloud'
entrypoint: bash
args:
- '-c'
- |
sed -i 's/%SECRET_KEY%/'${_SECRET_KEY}'/g' app.yaml
gcloud app deploy app.yaml
答案 2 :(得分:-1)
根据您突出显示的首选项(Cloud Build,KMS)。您提到的Google秘密链接涉及使用Cloud KMS:KeyRing和CryptoKey在构建或运行时存储敏感数据。但是,Google还提供了其他使用Cloud KMS的秘密管理解决方案。
您可以在storing Secrets期间使用以下两个其他选项:
选项1 :您可以将秘密存储在代码中,并使用Cloud KMS的密钥对进行加密。 (通常通过在应用程序层加密您的机密来使用。)
好处:为内部威胁提供了安全性层,因为它限制了对带有相应密钥的代码的访问 。
[您可以在Google文档here中找到有关这些选项的其他信息。]
选项2:您可以在Google存储空间 Bucket 中存储秘密,其中数据位于 {{ 3}} (类似于选项1,它可以将对机密的访问权限限制为一小组开发人员。)
好处:将您的机密存储在单独的位置中可确保如果违反了您的代码存储库 >,您的秘密仍可能受到保护。)
[注意:Google建议您将两个项目用于正确的rest encryption.。一个项目将使用Cloud KMS来管理密钥,另一个项目将使用Cloud Storage来存储密钥。]
如果上面列出的选项仍然不能满足您的需求,我发现一个separation of duties与您的项目有着相似的目标。 (即:将环境变量存储在无数据存储区中)
此StackOverflow question上提供的解决方案说明了将密钥存储在client_secrets.json文件中的用法,该文件通过在.gitignore中列出而在上传到git时被排除在外。您可以找到link的一些 Google 示例(Python)。