CI/CD 环境中的凭证管理

use*_*472 5 credentials continuous-integration

设置:我有一个应用程序,我目前在服务器上手动部署。它需要多个凭据(外部服务的客户端机密、令牌以及 AES 密钥和 IV 等),我目前已将这些凭据存储在使用gpg. 每当我重新启动应用程序时,我都会gpg在控制台中解锁-key,然后服务将从应用程序脚本中再次解密文件(因为gpg-agent密码在内存中保留有限的时间)并通过管道解析它们。

这种方法的优点是,gpg访问它们所需的凭据和-passphrase 都不会持久化到磁盘,只保存在内存中。因此,即使具有完全的 root 访问权限,也无法恢复凭据。唯一的机会是在gpg-key 保持解锁状态的短时间内获得访问权限。

缺点是 (a) 其他用户无法启动该服务(除非我们共享我的帐户)和 (b) 应用程序无法通过任何自动方式启动。

github 上的creds项目与我正在做的类似,但仍然存在上述缺点。可以使用多个gpg密钥对文件进行加密,然后尝试使用所有密钥对其进行解密,直到成功为止。

问题:有什么更好的方法来处理 (a) 多个用户无需共享密钥或帐户即可访问的凭据,(b) 可通过 CI/CD 系统访问(每次部署发生时我都没有控制台), (c) 只在内存中保存密码数据?使用多个gpg键的“解决方法”看起来像一个复杂的黑客,并且不适用于 CI/CD 系统。

fue*_*ero 3

我将讨论秘密而不是凭据,因为可能还有您想要保护的其他敏感信息。您的问题是否专门针对 CI/CD 系统并不重要,无论我们讨论的是使用 X.509 证书进行身份验证、保存数据库凭据还是保护构建代理的访问令牌,问题都是一样的。

没有规范的方法来处理这个问题,因为应用程序和组织的需求在秘密的构成以及如何处理它们方面有所不同。某些应用程序可能不提供除文件之外的其他存储机密的方法。

一些应用程序对磁盘上的秘密进行加密,但由于它们通常必须是对称的,因此或多或少具有装饰性。

所以,你可以做什么?

  • 您的第一道防线是操作系统的 DAC(自主访问控制)和 MAC(强制访问控制) - 如果我们谈论 Linux,则 POSIX 权限是 DAC,而 App Armor、SELinux 或 GRSecurity 等 LSM 是 MAC。

  • 根据CISDISA STIG等适当标准审核您的操作系统。

  • 人们会想到使用HSMOpenPGP 智能卡来存储用于加密磁盘上机密的 PGP 密钥。此类设备可保证密钥永远不会离开硬件。

请记住,没有任何单一措施可以保证 HSM 中密钥的安全 - 物理访问仍然可能会损害它们。硬件密钥存储设备必须与物理安全和正确的操作程序相结合,以加强其安全性。

检查主要浏览器的根 CA 策略(ChromeFirefoxEdge/IE)。他们强制使用硬件加密设备,以及有关如何操作它们以及必须通过哪些审核的一些限制和规则。

  • 使用Vault这样的软件来按需获取秘密,但这需要应用程序支持。否则,您只是再次将其存储在磁盘上。Vault 可以添加的内容是可强制执行的秘密 TTL 以及自行轮换秘密的能力。