这是否旨在包括 SSL 证书和密钥文件，它们可以是“大”（至少是 kb 的倍数），并且（取决于格式），通常包含不可打印的字符（至少是换行符）。
或者环境是否只是指向证书/密钥文件名？（例如，在尝试通过 Docker 部署时，这似乎并不理想——我们真的不想在 docker 映像中存储私钥，对吗？但也许这是一个单独的问题。）
问问题
1454 次
3 回答
4
SSL 证书（严格来说）不是配置，而是资产文件。
您如何提供此资产取决于您的托管方式。但这里有一些选择：
一种简单的方法是集成letsencrypt并使用certbot，它可以安全地自动处理证书的下载。letsencrypt 对某些语言进行了一些集成（例如，go 有多个可以集成到应用程序中的客户端）。
您可以使用负载均衡器并在负载均衡器处终止 ssl。在这种情况下，您的应用程序不需要知道有关证书的任何信息。
Kubernetes 提供了可以安全存储证书并在部署时将这些文件复制到 pod 的秘密（简化：pod 是一个包，它对包含您的应用程序的 docker 容器进行了薄薄的包装）。
Kubernetes 还可以将 Ingress 用作终止 ssl 的 LoadBalancer。
另一种选择是使用 hashcorp 的 Vault。这是一项管理和分发机密的服务。
当然，还有更多选择，这些只是提示。但是 ssl 证书的安全存储和分发并非易事。我希望我已经给出了一些好的提示。
于 2018-02-15T09:16:56.263 回答
1
我不是 12 要素应用程序最佳实践方面的专家；但是，从有关 12 因素应用程序配置的链接文章中，听起来规定的做法是使用环境变量来识别程序的可配置方面。
也许SSL_CERT_FILE和SSL_KEY_FILEenv vars 可以被读取为相应文件的路径，以便在文件可能位于不同位置的不同环境中轻松覆盖它们。
我个人喜欢无需额外配置即可“正常工作”的软件，因此您也可以考虑将证书和密钥文件嵌入可执行文件本身（如果可行的话），以便程序“开箱即用”但用户如果环境或特定应用程序需要，程序还可以指定备用证书/密钥文件位置。
于 2017-12-13T17:45:24.703 回答
-1
有不同种类的配置元素。12 要素应用程序在环境中存储配置的动机是为了一个特定的目标：使其易于在新环境中的其他地方重新部署。因此，只有那些配置元素才有资格进入有助于实现这一目标的环境。其他领域或应用程序特定的配置元素可以保持与应用程序的本地或技术特定配置方法的选择捆绑在一起。
对于 SSL 证书，这些证书似乎不会因环境而异，因此您不必将它们保存在环境变量中，IMO。
于 2016-05-18T15:17:24.103 回答