我们有代码(在 git 中)以及配置/部署/构建脚本(fabfile.py、circle.yml、Dockerfile 等)，这导致了非常无缝的自动构建/部署过程。不无缝的部分是存储各种凭证的位置。这些是诸如 ssh key 、代码签名证书、aws 访问 key 、ssl 证书之类的东西...目前的过程是从闪存驱动器复制所需的 key /证书，然后(例如)运行 Fabric。
看起来像这样在 git 中存储凭证(与代码一起)并不是最好的地方，但是什么是最好的地方呢？是否有推荐的最佳实践来为开发人员存储此类信息？是否有引用资料讨论不同选项的优缺点？
最佳答案
secret 管理的问题仍然没有通过使用任何工具来“解决”。
您可以使用各种 secret 管理工具中的任何一个(每个工具都提供不同类型的好处/集成)。
我个人更喜欢 Hashicorp Vault。 Cyberark 是另一个不错的选择。
但是，您在解决方案中使用这些工具的方式有一些常见的使用模式。
1) 您可以将 secret 存储在 SCM 中的代码中(如果它们已加密)...但这仍然会导致相同的问题，您仍然需要在部署时安全地传递 secret (或在启动时提供它)能够解密已部署的 secret (密码、凭据、 secret 、证书)。这就是 secret 管理工具(例如保管库)的用武之地。该工具将允许您安全地检索您的 secret ，以便在需要时用于解密 secret 。
2)上面提到的另一种方式是。实际上是将 SCM 之外的所有 secret 、证书等存储在 secret 管理工具本身中，并在部署/启动时检索它们。
显然，无论哪种方式都有利有弊。即第一种方法降低了复杂性，因为您在任何给定时间只管理一个或两个 secret 。另一方面，如果您将所有 secret 存储在保管库中，则与整个生态系统相关的妥协的可能性就会降低，因为访问单个 secret 不允许某人访问所有其他 secret 。
归根结底，这一切都取决于您的用例/可用的安全结构，当然还有您周围的人。因为归根结底，某人、某个地方需要知道一个 secret ......
关于ssl-certificate - 在哪里存储 DevOps 的凭据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40315155/