Kubernetes：Rails 凭证还是 ConfigMap / Secret 方式？

Question

我将我的Rails 6 应用程序部署在Kubernetes 集群中，并考虑如何实现我的ENV 变量。

我经常在 Rails 应用程序中使用 dotenv 和主机上的常规 ENV 变量。但看来，我现在可以省略它们并使用 Rails 凭据。但仅仅因为功能存在并不意味着它必须被使用或必须更好，对吧？

所以我不确定如何解决这个环境/安全难题：

接近 ConfigMap

• 在集群上创建一个ConfigMap以提供ENV vars
• 将所有 ENV 变量放入 ConfigMap 中
• 省略 Rails 凭据

方法凭证

• 提供 Kubernetes Secret 或带有 RAILS_MASTER_KEY 的 ConfigMap
• 为我需要的所有变量使用 Rails 凭据
• （某些 ENV 变量是否必须保留在像 RAILS_ENV 这样的 ConfigMap 中？）

我担心的缺点是，当我想更改 ENV var（修复拼写错误、缩放工作者、切换数据库、凭据...）时，我必须通过很多步骤：进行 git push、构建并标记容器并等待部署。 使用 ConfigMap 我只需 kubectl apply 进行更改。

我喜欢 Rails 的“约定优于配置”的方式，因此将 vars 分散到两种或三种不同的类型对内存来说似乎不太实用，但恐怕我必须这样做。

• 哪种方法更安全？

• 哪一个更“高效”或“开发人员友好”？

• 那么什么时候使用凭证？

• 2021 年的最佳做法是什么？

Answer 1

您不会（仅）使用 ConfigMap，因为这不安全，但您可以使用 Secret 以与您描述的方式相同的方式保存所有 env var。真的取决于您喜欢哪种工作流程。不管你怎么做，你在某个地方都有一些 Kubernetes Secrets 对象，只是它的范围问题。所以你 100% 需要有一个工作流程来处理这方面的事情。但是，如果您更喜欢通过 Rails 工作流程进行日常机密编辑，这样您就不需要过多地接触 Kubernetes 方面，那就太好了。

我个人认为减少涉及机密数据的系统会更好，即使这意味着 Rails 开发人员需要学习新工具。