如何避免在版本控制中存储密码?

发布于 2024-08-04 19:15:38 字数 519 浏览 4 评论 0原文

您使用什么策略来避免在版本控制中存储密码?

目前,我将开发/测试/生产密码保存在三个不同的文件中,并在部署期间使用适当的文件。所有这些都致力于版本控制,但我对此并不太满意,因为并非所有开发人员都需要知道这些密码(尤其是外包开发人员,它们只有在项目持续期间才能访问,可能只有一个月)。

在数据库中存储密码不是一个很好的选择:

  • 我在 Spring 上下文(Java 应用程序)初始化期间需要大部分数据,并且我不想构建用于连接到单个数据库的脚手架,然后再连接到其余数据库数据库和初始化应用程序的其余部分
  • 一些密码仅与部署相关;访问不同服务器、密钥库等的密码;这些是应用程序启动后无法加载的内容,因为它根本不加载它

我正在考虑将部署配置从开发人员计算机移动到专用计算机,该计算机从版本控制中检查代码并运行构建/部署脚本,但我不太确定最好的方法是什么。

我还需要说的是,我不想要最终的安全性:我只是想避免每个开发人员的磁盘上都有密码并使其变得太容易。

所以我想询问您的经验/最佳实践。你怎么做?

What strategy do you use to avoid storing passwords in version control?

Currently, I have development/test/production passwords saved in three different files and the appropriate file gets used during deployment. All this is committed to version control, but I'm not too happy with that since not all developers need to know those passwords (especially outsourced ones, which have access only while their projects last, which could be only a month).

Storing passwords in database is not a great option:

  • I need most of the data during the initialization of Spring context (Java app), and I don't want to build scaffolding for connecting to a single database, and afterwards connecting to the rest of databases and initializing the rest of application
  • some of the passwords are only deployment-related; password to access different servers, keystores, etc.; those are the things application can't load after it starts, since it doesn't load it at all

I'm thinking about moving deployment configuration from developer machine to dedicated computer which checks out code from version control and runs build/deployment script, but I'm not really sure what would be the best way to do it.

I also need to say that I don't want ultimate security: I just want to avoid having passwords on every developer's disk and making it too easy.

So I'm asking for your experiences/best practices. How do you do it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

扛刀软妹 2024-08-11 19:15:38

特定于环境的配置属性 我倾向于放入不在源代码管理中且不属于构建过程的属性文件。设置新环境时,设置的一部分是创建属性文件,其中包括数据库地址、凭据和名称、相关远程主机的名称等。

在 Spring 中,您使用 PropertyPlaceholderConfigurer 加载属性文件。它只需要能够被 Spring 找到,这通常意味着将它放在应用程序服务器下的适当目录中。

或者,您可以使用 wrapper 来运行应用程序服务器,并且 JVM 启动选项包括添加将这些属性文件添加到类路径中,以便 Spring 可以找到它们。

Environment-specific configuration properties I tend to put in, say, a properties file that isn't in source control and isn't part of the build process. When setting up a new environment, part of that setup is to put create that properties file that includes things like database addresses, credentials and names, names of relevant remote hosts and so on.

In Spring you use the PropertyPlaceholderConfigurer to load the properties file. It just needs to be findable by Spring, which usually just means putting it in an appropriate directory under the application server.

Alternatively, you use wrapper to run the application server and the JVM startup options include adding these properties files to the classpath so Spring can find them.

残花月 2024-08-11 19:15:38

我见过两种方法:

  • 将密码移至开发人员无权访问的另一个源代码控制树中。
  • 不要将任何密码放入源代码管理中,并且每次部署完成时,专门的构建经理都需要输入密码。这是在一家银行,有一个全职人员负责构建流程/合并/发布。

I've seen two approaches to this:

  • Move the passwords into another tree of source control that developers don't have access to.
  • Don't put any passwords into source control, and the dedicated build manager person needs to type in the passwords every time a deploy is done. This was in a bank where there was a full time guy working on build processes / merging / releases.
原谅我要高飞 2024-08-11 19:15:38

这并非在所有情况下都有效,但这就是使用 NT AUTHORITY\NETWORK SERVICE 作为服务身份的荣耀所在。如果您使用此身份,则无需为其维护密码 --您可以仅使用 DOMAINNAME\MACHINENAME$ 形式的计算机 AD 凭据来执行受保护的网络和数据库访问。

当然,有一些关键的事情需要注意——最重要的是,共享安全边界的两个应用程序不能像这样托管在同一台服务器上。

This doesn't work in all cases, but this is where the gloriousness of using NT AUTHORITY\NETWORK SERVICE as the identity of your services comes in. If you use this identity, you don't need to maintain a password for it -- you can just use the Computer's AD credentials in the form of DOMAINNAME\MACHINENAME$ to do your protected network and database access.

There are, of course, some key things to watch out for -- not the least of which is that no two apps which share a security boundary are hosted like this on the same server.

那些过往 2024-08-11 19:15:38

将密码放入操作系统用户环境变量中。

只有该用户或 root 可以读取该值,与文件相同,但将其签入源代码管理的可能性为零。

Put the passwords in o/s user environment variables.

Only that user or root can read the value, same as a file, but with zero chance of it getting checked into source control.

尘世孤行 2024-08-11 19:15:38

我认为在存储库之外有一个 local_settings 是很好的。

https://stackoverflow.com/a/21570849/1675586

I think it's good to have a local_settings outside of the repository.

https://stackoverflow.com/a/21570849/1675586

甜宝宝 2024-08-11 19:15:38

您可以以加密形式存储它们,而不是不存储它们。因此,您不必在新开发人员开始时一直通过 IM 或电子邮件发送凭据文件。您只需告诉他们一次项目特定的主密码,以便他们可以加密凭据。

Instead of not storing them, you could store them in encrypted form. So you dont have the pain of sending credentials files via IM or EMail all the time a new developer starts ... You just need to tell them the project specific master-password once so they can encrypt the credentials.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文