首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >服务器/数据库配置文件,包括密码,是否应该存储在源代码管理中?

服务器/数据库配置文件,包括密码,是否应该存储在源代码管理中?
EN

Stack Overflow用户
提问于 2010-11-22 15:22:51
回答 11查看 11.4K关注 0票数 51

我想听听一些最佳实践。

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

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

编辑:增加了一项奖励,以鼓励更多的讨论,并听取更多的人认为最佳实践。

EN

回答 11

Stack Overflow用户

回答已采纳

发布于 2010-12-01 06:34:22

这里没有唯一的“银弹”答案,这在很大程度上取决于细节。

首先,我认为最好的做法是将所有源代码与配置分开放在单独的存储库中。因此,源代码仍然是源代码,但它的安装或部署(包括配置、密码等)则完全是另一回事。这样,您就可以将开发人员的任务从系统管理员的任务中分离出来,并最终可以建立两个不同的团队,做他们擅长的事情。

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

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

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

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

我们有什么让它们连接在一起并充分发挥作用?

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

请注意,这里有两种不同的“类型”信息:IPs/主机名是固定的,您可能希望一次性分配它们。另一方面,登录和密码(甚至数据库名称)在这里纯粹是为了连接目的-以确保连接到它的是我们的MySQL应用程序。因此,我在这里的建议是将这两种“类型”分开:

应将IP等永久信息存储在某些VCS中(不同于源代码VCS)

  • "Transient“信息,如2个应用程序之间的密码,决不能存储,而应在生成部署包时生成。

最后也是最棘手的问题仍然存在:如何创建部署包?有多种可用的技术,主要有两种方法:

  • 从VCS1导出源代码+从VCS2“永久”配置+从VCS3构建脚本= packages
  • Source代码在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个应用程序服务器中的每一个上。理想情况下,它应该能够安装在干净安装的OS上,并在没有任何手动activity.
  • my-application-mysql的情况下创建完全工作的应用程序集群节点-这将依赖于MySQL - server
  • checks,并将包括以下安装后脚本:
    • 启动MySQL服务器,并确保它将在OS start
    • connects上自动启动,如果所需的数据库存在,则连接到
    • 如果否,则创建数据库,使用内容引导它,并使用密码创建登录(使用/etc/my-php-application/config.inc.php,使用md5 server生成的相同的登录和密码是-连接到数据库,应用迁移以将其升级到新版本,取消所有较旧的登录名/密码,并重新创建新的登录名/密码对(同样,使用md5(修订版+ salt) method)

生成

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

这个相当简单的示例说明了您可以在这里使用的许多方法-但最终,您可以决定哪种解决方案在这里更好,哪种解决方案过于夸张。如果您在这里或作为一个单独的问题提出更多细节,我将很乐意尝试进入细节。

票数 28
EN

Stack Overflow用户

发布于 2010-11-22 15:28:45

抛开密码永远不应该以纯文本形式存储在任何地方(除了某人的头盖骨或只有首席执行官、首席财务官和首席信息官才能访问的上了锁的保险库(并且同时需要这三个密钥))这一点,您应该将构建您的产品所需的所有内容都存储到源代码控制中( build your product )。

这不仅仅意味着你的源代码,甚至是构建机器的规范,编译器选项,编译器本身等等。

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

构建过程本身可以复制的任何东西,或者用于运行而不是构建软件的任何东西(例如您的密码)通常不属于源代码控制之下,但一些商店会对其可执行文件、生成的文档等执行此操作,以便他们可以快速获得特定的发行版以进行安装。

票数 18
EN

Stack Overflow用户

发布于 2010-11-25 22:53:01

密码不应存储在源代码管理中。完全没有。永远不会。请参阅How to keep secrets secret

密码、服务器名称等是服务器管理员执行的部署配置的一部分。将此程序文件化,并将文件化的程序置于控制之下,这一点至关重要。

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

除了服务器配置之外,其他所有东西都必须在源代码控制中使用

将服务器配置存储在源代码管理中通常不是一个好主意,因为它会阻碍部署,并可能导致小灾难(例如,当有人没有意识到从源代码管理部署的测试版本正在与实时服务通信时)。

请始终将这些配置文件保存在webroot之外。

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

在Windows上运行时,

  • 使用集成身份验证。请参阅Securing Data Access
  • MySQL配置以允许从本地主机进行连接,并且不需要密码。请参阅您可以使用~/.pgpass.

Step 7: Securing a MySQL Server on Windows

  • PostgreSQL
票数 11
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/4243174

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档