在持续部署中管理密码答案

【问题标题】：Managing passwords in continuous deployment在持续部署中管理密码
【发布时间】：2012-03-17 06:16:33
【问题描述】：

我们正在使用 TeamCity 部署持续集成环境。当我们完成 CI 流程并转向持续部署时，我们遇到了如何管理生产密码的问题。对于配置中的其他更改，我们使用 Web.Config 转换。但是，我真的不想在构建配置文件中烘焙生产密码。

在 CI/CD 之前，我们将获取 Web.config，使用 aspnet_regiis 解密连接字符串，更改密码，然后重新加密。显然，这很容易出错，而且完全不符合 CI/CD 的精神。

我还有其他几个想法，基本上都是关于在部署脚本中使用某些东西来重写然后加密文件的连接字符串部分，但这似乎是一个常见问题，并且必须是一些普遍接受的解决方案。但到目前为止，我找不到它。有没有“正道”？

谢谢！

【问题讨论】：

如果您要使用 CD，那么显然您构建/部署链中的 something 必须知道密码（或密码的代理）。
How to configure TeamCity with private files?的可能重复
@Damien_The_Unbeliever 是的，但可以是 TeamCity 服务器，与您的 VCS 不同的人可以访问该服务器。
这篇文章概述了为什么以及如何在代码和 CI/CD 中避免明文凭据：medium.com/twodigits/…
本文介绍了如何在 TeamCity 中管理凭据：pinter.org/archives/3681 请注意，到目前为止，这仅提供有限的安全性，因为密码只是加扰，请参阅：youtrack.jetbrains.com/issue/TW-45181

【解决方案1】：

自 TeamCity 7.0 起可用的一种可能解决方案是使用 typed parameters。您可以在 TeamCity 中定义密码类型的参数，并以某种方式将其传递给您的构建脚本（作为环境变量或作为您的构建脚本属性）。

TeamCity 将此类参数的值存储在其自己的配置文件中，并以加扰的形式存储在数据库中。如果密码出现在构建日志或构建参数页面上，它将被替换为 ***。

【讨论】：

请注意，原始密码可能会出现在日志中，甚至 TeamCity 网站也会说：“将参数设置为输入密码并不能保证无法检索原始值。”我遇到的情况：当您的 git push 失败时，它会打印“请求的 URL 返回错误：访问时出现 400 Bad Request”这一行。因此，如果您使用带有用户/密码信息的 git url，即使您以适当的方式输入，这里的密码也不会被替换为 ****

【解决方案2】：

使用配置转换。您甚至可以构建自己的转换来处理加密/解密。最简单的方法是加密 release.web.config 中的生产字符串并使用转换来处理替换连接字符串。

如果这对您不起作用，请使用构建后事件调用 aspnet_regiis。如果你选择扩展配置转换，你可以用它做任何事情。只要你能拿到加密密钥，它们就可以在月球上。

【讨论】：

【解决方案3】：

你不能在 iis 中定义连接字符串吗？他们变化很大吗？我想我只是在 IIS 中为网站设置它们，然后不将它们部署为应用程序的一部分，或者至少优先考虑我的 IIS 设置。

【讨论】：