我希望听到一些最佳做法...
假设一个 Web 应用程序与几个不同的生产服务器（数据库等）交互...是否应该将包含数据库密码的配置文件存储在源代码控制中（例如 git、svn）？
如果没有，跟踪您的应用程序需要访问的服务器数据库（或其他相关）密码的最佳方法是什么？
编辑：添加了赏金以鼓励更多讨论并听取更多人认为的最佳做法。
【问题讨论】：
标签： svn git version-control passwords config
撇开密码不应该以纯文本任何地方（除了某人的颅骨或只有 CEO、CFO 和 CIO 才能访问的锁定保险库（并且同时需要所有三个密钥） ))，您应该将构建您的产品所需的所有内容都存储到源代码管理中。
这不仅意味着您的源代码，还包括构建机器的规范、编译器选项、编译器本身等等。
如果我们能找到检查物理硬件的方法，我们也会这样做:-)
构建过程本身可以复制的所有内容，或运行而不是构建软件的任何内容（例如您的密码）通常不属于源代码控制，但有些商店会这样做他们的可执行文件、生成的文档等，以便他们可以快速获取特定版本进行安装。
【讨论】：
我更喜欢在主 settings 文件旁边有一个 local_settings 文件。这个 local_settings 不应该添加到存储库中，但我会在存储库中添加一个 sample.local_setting 以显示此文件的结构。
在运行时，如果 local_settings 存在，其值将覆盖主设置文件的值。
例如在python中：
settings.py：
log='error.log'
db=lambda:None
db.host='localhost'
db.user=''
db.password=''
try:
import local_settings
except ImportError:
pass
local_settings.py：
from settings import *
db.user='abcd'
db.password='1234'
【讨论】：
如果没有正确的构建过程，我正在使用这个策略（对于 PHP 应用程序）：
/etc/companyname
在里面放两个文件：
<?php // env.php
return 'prod';
<?php // appname-prod.php
return array(
'db' => array( /* credentials */ ),
/* other host-specific conf data */
);
使这两个文件只能由您的 PHP 进程读取
现在您应用的配置文件将类似于：
<?php // config.php
$env = (require "/etc/companyname/env.php");
$creds = (require "/etc/companyname/appname-{$env}.php");
有了这个，环境定义了使用的凭据，您可以在预配置的环境之间移动代码（并使用$env 控制一些选项）。当然，这可以通过服务器环境变量来完成，但是这 a) 设置起来更简单 b) 不会向服务器上的每个脚本公开凭据（不会出现在像 phpinfo() 这样的杂散调试垃圾中)。
为了在 PHP 之外更容易阅读，您可以将凭证文件设为 JSON 或其他内容，然后忍受微小的性能损失（APC 不会缓存它们）。
【讨论】：
源代码中的密码问题：
我发现最好的方法是检查一个配置，该配置使用混合默认值和占位符来存储特定于部署的数据。我们的应用程序总是寻找允许覆盖任何变量的系统配置。这允许生产机器拥有适合其部署的配置。
注意：当我担任管理员时，我总是将配置与代码分开管理（有充分的理由）。
【讨论】：
密码不应存储在源代码管理中。完全没有。曾经。见How to keep secrets secret
密码、服务器名称等是服务器管理员执行的部署配置的一部分。必须记录此程序并将记录的程序置于控制之下。
或者，部署配置可以由系统管理员运行以执行配置的脚本来执行，并且在脚本执行期间它会要求系统管理员提供所需的信息。同样，此脚本必须保存在版本控制中。
除服务器配置之外的所有其他内容必须在源代码管理中。
在源代码管理中存储服务器配置通常是一个坏主意，因为它会妨碍部署并可能导致小灾难（例如，当有人没有意识到他们从源代码管理部署的测试版本正在与实时服务通信时） .
始终将这些配置文件保存在 webroot 之外。
可信连接可能是一个选项，允许已知 IP 地址通过该服务的配置连接到服务..
【讨论】：
我总是排除包含密码或其他访问详细信息（如数据库）的重要配置文件，这纯粹是最佳实践。此外，源代码和版本控制通常为多个用户提供服务，并且并非所有用户都使用相同的数据库详细信息，甚至使用相同的服务器配置（域等），为此，配置文件应保持排除在他之外一大堆。
【讨论】：
示例配置文件，当然，我会将它们置于版本控制之下。但通常不会使用真实世界的访问数据，例如服务器地址或密码。更多类似的东西
# 程序.conf # # $myprog 的 mysql 选项。 # #SERVER_ADDR=127.0.0.1 #SERVER_USER=mysql #SERVER_PASSWD=abcdef【讨论】：
这里没有单一的“灵丹妙药”答案，这在很大程度上取决于细节。
首先，我认为最佳做法是将所有源代码与单独存储库中的配置分开。因此，源代码仍然是源代码，但它的安装或部署（使用配置、密码等）是另一回事。这样，您就可以将开发人员的任务与系统管理员的任务牢牢分开，并最终建立两个不同的团队来做他们擅长的事情。
当您拥有单独的源代码存储库 + 部署存储库时，您最好的下一个选择是考虑部署选项。我在这里看到的最佳方式是使用所选操作系统的典型部署过程（即按照操作系统维护者的方式为所选操作系统构建自主包）。
例如，Red Hat 或 Debian 打包程序通常意味着从外部站点获取一个 tarball 软件（这将是从您的源代码 VCS 导出源代码）、解包、编译和准备包以准备部署。理想情况下，部署本身应该意味着只需执行一个快速简单的命令来安装软件包，例如rpm -U package.rpm、dpkg --install package.deb 或 apt-get dist-upgrade（假设您构建的软件包会转到 apt-get 能够找到的存储库他们）。
显然，要使其以这种方式工作，您必须为处于完全工作状态的系统的所有组件提供所有配置文件，包括所有地址和凭据。
为了更简洁，让我们考虑一个典型的“小服务”情况：一个 PHP 应用程序部署在 n 个运行 apache/mod_php 的应用程序服务器上，访问 m 个 MySQL 服务器。所有这些服务器（或虚拟容器，这并不重要）都驻留在受保护的专用网络中。为了让这个例子更简单，我们假设所有真正的互联网连接都由一组 k http 加速器/反向代理（例如 nginx / lighttpd / apache）组成，它们的配置非常简单（只是内部 IP转发到）。
我们需要什么才能让他们相互联系并充分发挥作用？
请注意，这里有 2 种不同“类型”的信息：IP/主机名是固定的，您可能希望一劳永逸地分配它们。另一方面，登录名和密码（甚至数据库名称）在这里纯粹是为了连接目的 - 以确保 MySQL 确实是我们的 PHP 应用程序连接到它。所以，我在这里的建议是拆分这两种“类型”：
最后一个也是最棘手的问题仍然存在：如何创建部署包？有多种技术可用，主要有两种方法：
对于上面的示例，我将创建如下包：
my-application-php - 这将取决于 mod_php、apache 并将包括像 /etc/my-php-application/config.inc.php 这样的生成文件，其中将包括 MySQL 数据库 IP/主机名和生成为 md5(current source code revision + salt) 的登录名/密码。该软件包将安装在每 n 个应用程序服务器上。理想情况下，它应该能够安装在干净安装的操作系统上，并在无需任何手动操作的情况下构建一个完全正常工作的应用程序集群节点。my-application-mysql - 这将取决于 MySQL-server 并包含以下安装后脚本：
/etc/my-php-application/config.inc.php 中生成的登录名和密码相同，使用 md5 算法）最终，它应该会带来使用 generate-packages && ssh-all apt-get dist-upgrade 之类的单个命令升级部署的好处。此外，您不会将跨应用程序密码存储在任何地方，并且它们会在每次更新时重新生成。
这个相当简单的示例说明了您可以在此处使用的许多方法 - 但是，最终由您来决定哪种解决方案在这里更好，哪种解决方案过于矫枉过正。如果您在此处或作为单独的问题提供更多详细信息，我很乐意尝试详细说明。
【讨论】：
在我的用于 PHP 的 Subversion 存储库中，包含密码的配置文件以 config.php.sample 签入，并提示必须提供的内容，并且依赖的脚本要求 config.php 出现在同一位置。
存储库配置为忽略该目录的config.php，以避免“意外”添加或签入。
【讨论】：
我认为这个问题更多地是关于信息所有权、信任和组织。您应该扪心自问，您会信任组织的哪一部分来保护您的系统密码不被泄露和滥用？
我曾在由负责业务的人员保管的组织中工作。在其他情况下，他们被委派给运营团队，该团队也负责创建和使用等流程。
最重要的是，在您的组织中明确定义了谁应该有权访问系统密码。之后，您可以决定保护密码的适当技术解决方案。
【讨论】：
总的来说，我同意 paxdiablo：将所有可能的内容置于源代码控制之下。这包括带有数据库凭据的生产配置文件。
想想你的服务器崩溃的情况，备份结果很糟糕，你需要让服务器恢复。我认为您和您的客户（或老板）肯定会同意，拥有在源代码管理中部署站点所需的一切是一大优势。
如果您想使用持续集成（另一种最佳实践）从源代码构建易于部署的软件包，您必须将配置文件置于源代码控制之下。
还要考虑到，在大多数情况下，拥有源代码控制访问权限的开发人员无法直接访问生产数据库服务器。生产密码对他们毫无用处。
如果错误的人访问了您的资源，他们仍然需要访问生产服务器才能破坏密码。所以，如果你的生产环境得到适当的保护，源代码管理中密码的安全风险是非常有限的。
【讨论】：
没有。生产密码应直接在服务器上配置。您应该为部署团队/人员创建部署说明，以便在部署期间更改正确的属性文件。
【讨论】：