使用github操作和github秘密将配置文件传递给Google Cloud函数
我在开发计算机上有一个config.py
文件,该文件为我的配置设置存储了多个词典。
config.py
:
SERVICE_ONE_CREDENTIALS = {
"CLIENT_ID": 000,
"CLIENT_SECRET": "abc123"
}
SERVICE_TWO_CREDENTIALS = {
"VERIFY_TOKEN": "abc123"
}
...
我最近设置了此 github action 要自动将被推到存储库的更改部署到Google Cloud函数中,并在尝试复制此配置文件时遇到问题,因为由于该文件存储了敏感的凭据,因此从GIT中忽略了该文件。
我一直在尝试找到一种将此文件复制到云功能的方法,但尚未成功。由于键的数量,我希望远离使用环境变量。我确实考虑使用密钥管理服务,但是我首先想看看是否可以将文件存储在GitHub Secrets中并将其传递给功能。
作为备份,我确实考虑过加密配置文件,将其添加到git reto中,并将解密密钥存储在github秘密中。这样,在开始应用程序工作流之前,我可以在云功能中解密文件。不过,这似乎不是一个好主意,但是很感兴趣地看看是否有人这样做或您对此有何想法。
这样的事情吗?
I have a config.py
file on my development machine that stores multiple dictionaries for my config settings.
config.py
:
SERVICE_ONE_CREDENTIALS = {
"CLIENT_ID": 000,
"CLIENT_SECRET": "abc123"
}
SERVICE_TWO_CREDENTIALS = {
"VERIFY_TOKEN": "abc123"
}
...
I recently setup this GitHub action to automatically deploy the changes that are pushed to the repository into a Google Cloud Function, and ran into a problem when trying to copy this configuration file over since the file is being ignore from git due to it storing sensitive credentials.
I've been trying to find a way to copy this file over to the Cloud Function but haven't been successful. I would prefer to stay away from using environment variables due to the number of keys there are. I did look into using key management services, but I first wanted to see if it would be possible to store the file in GitHub Secrets and pass it along to the function.
As a backup, I did consider encrypting the config file, adding it to the git repo, and storing the decryption key in GitHub secrets. With that, I could decrypt the file in the Cloud Function before starting the app workflow. This doesn't seem like a great idea though, but would be interested to see if anyone has done this or what your thoughts are on this.
Is something like this possible?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您加密并放入存储库,至少是不清楚的文字,并且没有私钥就无法秘密(当然,您不会检查哪个)。我在Dotfiles回购中做类似的事情,在其中我用秘密检查了DAT文件,而私钥未签入。这有点机械,但可能。
使用GitHub Secrets是一条安全的路径,因为您没有签入任何东西,它已牢固地存储,如果引用了它,我们将其通过。不顾一切,我从事行动。
一个考虑因素是我们从日志中随机编辑了秘密,但一次完成了一行。多行秘密不好。
因此,有几个选项...
您可以将实际的秘密(ABC123)作为秘密管理,并与秘密相呼应配置文件。正如您指出的那样,您必须单独管理每个秘密。恕我直言,这没什么大不了的,因为ABC123实际上是秘密。我可能会倾向于那条路。
另一个选项是base64编码配置文件,将其作为秘密存储在github操作中,然后将Echo base64解码为文件。不用担心,Base64不是这里的安全机制。它是将其转到一条线路的运输方式,如果它意外地泄漏到日志中(您运行的命令行),将从日志中删除它的base64版本(很容易被解码)。
可能还有其他选择,但希望有所帮助。
If you encrypt and put in a repo at least it's not clear text and someone can't get to the secret without a private key (which of course you don't check in). I do something similar in my dotfiles repo where I check in dat files with my secrets and the private key isn't checked in. That would have to be a secret in actions and written to disk to be used. It's a bit of machinery but possible.
Using github secrets is a secure path because you don't check-in anything, it's securely stored and we pass it JIT if it's referenced. dislosure, I work on actions.
One consideration with that is we redact secrets on the fly from the logs but it's done one line at a time. multiline secrets are not good.
So a couple of options ...
You can manage the actual secret (abc123) as a secret and echo the config file to a file with the secret. As you noted you have to manage each secret separately. IMHO, it's not a big deal since abc123 is actually the secret. I would probably lean into that path.
Another option is to base64 encode the config file, store that as a secret in github actions and echo base64 decoded to a file. Don't worry, base64 isn't a security mechanism here. It's a transport to get it to a single line and if it accidentally leaks into the logs (the command line you run) the base64 version of it (which could easily be decoded) will be redacted from the logs.
There's likely other options but hope that helped.