服务器/数据库配置文件(包括密码)是否应存储在源代码管理中？

Question

我希望听到一些最佳实践......

假设一个Web应用程序与几个不同的生产服务器(数据库等)交互......包含数据库密码的配置文件是否应该存储在源代码管理中(例如,git,svn)？

如果没有,跟踪应用程序需要访问的服务器数据库(或其他相关)密码的最佳方法是什么？

编辑:增加了赏金以鼓励更多讨论,并听取更多人认为最佳做法.

Answer 1

这里没有单一的"银弹"答案,这在很大程度上取决于细节.

首先,我考虑将所有源代码与单独存储库中的配置分开的最佳实践.因此,源代码仍然是源代码,但它的安装或部署(包括配置,密码等)是另一回事.通过这种方式,您可以将开发人员的任务与系统管理员的任务完全分开,最终可以构建2个不同的团队来完成他们擅长的任务.

当您拥有单独的源代码存储库+部署存储库时,您最好的下一个选择是考虑部署选项.我在这里看到的最好的方法是使用典型的选择操作系统的部署过程(即为操作系统维护人员的方式为所选操作系统构建自治包).

例如,Red Hat或Debian打包程序通常意味着从外部站点获取软件的tarball(将从源代码VCS导出源代码),解压缩,编译和准备准备部署的软件包.理想情况下,部署本身应该只是执行一个快速简单的命令来安装软件包,例如rpm -U package.rpm,dpkg --install package.deb或者apt-get dist-upgrade(假设您构建的软件包转到apt-get能够找到它们的存储库).

显然,为了让它以这种方式工作,您必须为处于完全工作状态的系统的所有组件提供所有配置文件,包括所有地址和凭证.

为了更简洁,让我们考虑一个典型的"小服务"情况:一个PHP应用程序部署在运行apache/mod_php的n个应用程序服务器上,访问m个 MySQL服务器.所有这些服务器(或虚拟容器,实际上并不重要)都驻留在受保护的专用网络中.为了使这个例子更容易,让我们假设所有真正的互联网连接都是由一组k http加速器/反向代理(例如nginx/lighttpd/apache)提供的,它们具有非常简单的配置(只需转发内部IP).

我们有什么能让他们联系起来并充分发挥作用？

• MySQL服务器:设置IP /主机名,设置数据库,提供登录和密码
• PHP应用程序:设置IP /主机名,创建配置文件,提及MySQL服务器的IP,登录,密码和数据库

请注意,此处有两种不同的"类型"信息:IP /主机名是固定的,您可能希望一劳永逸地分配它们.另一方面,登录和密码(甚至数据库名称)纯粹是为了连接目的 - 为了确保MySQL真的是我们连接到它的PHP应用程序.所以,我在这里推荐的是分割这两种"类型":

• "永久"信息(如IP)应存储在某些VCS中(与源代码VCS不同)
• "瞬态"信息(例如2个应用程序之间的密码)应该永远不会存储,而是在生成部署包期间生成.

最后和最棘手的问题仍然存在:如何创建部署包？有多种技术可供选择,主要有两种方法:

• 从VCS1中导出的源代码+来自VCS3 +包的VCS2 +构建脚本的"永久"配置
• 源代码在VCS1中; VCS2是一个分布式版本控件(如git或hg),它基本上包含VCS1 +配置信息的"分支"+可以生成的构建脚本.我个人更喜欢这种方法,它更短,最终更容易使用,但学习曲线可能会更陡一些,特别是对于那些必须掌握git或hg的管理员来说.

上面的例子,我创建了如下包:

• 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服务器,并将包括以下安装后脚本:
  • 启动MySQL服务器并确保它将在OS启动时自动启动
  • 连接到MySQL服务器
  • 检查是否存在所需数据库
  • 如果不是 - 创建数据库,使用内容引导它并使用密码创建登录(/etc/my-php-application/config.inc.php使用md5算法生成的登录名和密码相同)
  • 如果是 - 连接到数据库,应用迁移将其升级到新版本,杀死所有旧登录/密码并重新创建新的登录/密码对(再次使用md5(revision + salt)方法生成)

最终,它应该使用单个命令来带来升级部署的好处generate-packages && ssh-all apt-get dist-upgrade.此外,您不会在任何地方存储应用程序间密码,并且每次更新时都会重新生成它们.

这个相当简单的例子说明了你可以在这里采用的许多方法 - 但是,最终,由你来决定哪个解决方案在这里更好,哪个解决方案过度.如果你在这里提出更多细节或作为一个单独的问题,我很乐意尝试详细介绍.

Answer 2

暂且不说密码永远不应该以明文形式存储在任何地方(除了某人的头盖骨或只能由CEO,CFO和CIO访问的锁定保险库(并且一次需要所有三个密钥)),您应该将所有内容存储在源代码管理中这是构建产品所必需的.

这不仅意味着您的源代码,还意味着构建机器,编译器选项,编译器本身等的规范.

如果我们能找到一种检查物理硬件的方法,我们也会这样做:-)

构建过程本身可以复制的任何东西,或者任何用于运行而不是构建软件的东西(例如密码)通常都不属于源代码管理,但有些商店会为其可执行文件,生成的文档等执行此操作,只需这样他们就可以快速获得特定的安装版本.

Answer 3

密码不应存储在源代码管理中.完全没有.永远.请参阅如何保密秘密

密码,服务器名称等是服务器管理员执行的部署配置的一部分.必须记录此程序并将记录的程序置于控制之下.

或者,部署配置可以由sysadmin运行以执行配置的脚本执行,并且在脚本执行期间,它将要求sysadmin提供所需的信息.同样,此脚本必须保留在版本控制中.

除服务器配置外,其他所有内容都必须在源代码管理中.

在源代码管理中存储服务器配置通常是一个坏主意,因为它妨碍了部署并可能导致小的灾难(例如,当有人没有意识到他们从源代码控制部署的测试版本正在与实时服务进行通信时).

始终将这些配置文件保留在webroot之外.

可信连接可以是一个选项,允许已知的IP地址通过配置该服务连接到服务.

• 在Windows上运行时使用集成身份验证.请参阅保护数据访问
• MySQL配置为允许来自localhost的连接,并且不需要密码.请参阅步骤7:在Windows上保护MySQL服务器
• PostgreSQL你可以使用〜/ .pgpass.

Answer 4

一般来说,我同意paxdiablo:把你可能拥有的一切都置于源代码控制之下.这包括具有数据库凭据的生产配置文件.

考虑一下服务器崩溃的情况,备份结果是糟糕的,你需要重新启动服务器.我认为您和您的客户(或老板)肯定会同意在源代码管理中部署网站所需的一切都是一大优点.

如果要使用持续集成(另一种最佳实践)从源构建易于部署的软件包,则必须将配置文件置于源代码管理之下.

还要考虑在大多数情况下,具有源代码控制访问权限的开发人员无法直接访问生产数据库服务器.生产密码对他们来说毫无用处.

如果错误的人获得了对您的来源的访问权限,他们仍然需要访问生产服务器才能破坏密码.因此,如果您的生产环境得到适当保护,源代码管理中密码的安全风险将非常有限.