如果我可以解码 Kubernetes 机密，那么它们的意义何在？答案

【问题标题】：What is the point of Kubernetes secrets if I can decode them?如果我可以解码 Kubernetes 机密，那么它们的意义何在？
【发布时间】：2020-08-04 10:51:50
【问题描述】：

我可以轻松获取Kubernetes中存储的秘密。

$ kubectl get secret my-app-secrets -o yaml

从输出中选择我要解码的秘密值。

例如ZXhwb3NlZC1wYXNzd29yZAo=

$ echo ZXhwb3NlZC1wYXNzd29yZAo= | base64 --decode
> exposed-password

我不确定我是否了解Kubernetes 生态系统中的秘密资源的有效性，因为它很容易获得。

【问题讨论】：

【解决方案1】：

base64 是编码，不是加密，它可以让您以方便的方式简单地对信息进行编码。

你编码的数据可能包含很多无法识别的字符、换行符等，所以编码起来很方便。

在 kubernetes 中，您可以使用 instruction 启用加密。

但 kubernetes 不应该是唯一的事实来源，而是 kubernetes 从您需要选择的外部保险库加载这些机密，例如 hashicorp's vault，如 cmets 中所示。

除了hashicorp vault，还有多种方法可以在git中存储秘密：

您可能还对kubesec 项目感兴趣，该项目可用于分析kubernetes 资源的安全风险。

【讨论】：

我想我仍然没有看到这种编码的用处以及为什么它“方便”。更不用说任何加密kubernetes.io/docs/tasks/inject-data-application/… 的建议了。我认为他们会促进更好的做法来存储编码的秘密，这些秘密不是公开密码/密钥的 1 个命令。

【解决方案2】：

关键在于，在 Kubernetes 中，秘密允许您通过控制对秘密的访问来保护您的密码（您想要通过加密来执行的操作），而不是通过加密它。

有几种机制：

也就是说，如果出现问题，Sealed Secrets created by Bitnami 或其他解决方案（请参阅 Mokrecov 答案）等解决方案已经出现，以使问题更加稳健，以防万一不受欢迎的人获得了您的秘密。

【讨论】：

【解决方案3】：

kubernetes 中的秘密是单独的清单，不是为了保护您的秘密数据，而是为了将您的秘密数据与您的部署/pod 配置分开。

然后由您决定如何保护您的秘密，有很多选择，它的优点和缺点（请参阅 Mokrecov 的回答）。与其他类型相比，秘密也有一些优势。和命名空间限制一样，单独的访问管理，在需要之前在 pod 中不可用，也不写入本地磁盘存储。

让我们换个角度想，让我们想象一下 kubernetes 中没有任何 Secret。现在，您的秘密数据将在您的部署/pod/configmap 中。你有几个问题。例如：

您希望向所有用户授予对部署清单的访问权限，但将对机密的访问权限仅限于人员 A 和 B。你是怎么做到的？
如果要加密机密，则必须将所有数据与部署数据一起加密，这将使维护变得不可能。或者你可以加密每个秘密值，但你必须为每个秘密值想出一些解密机制，而且解密的密钥在那个阶段无论如何都是无效的。
您可以使用 ConfigMap 将秘密数据与配置分开。但是当你想添加加密机制，或者对它进行一些访问限制时，你会受到 ConfigMap 特性的限制，因为它的目的只是存储非机密数据。使用 Secrets，您可以轻松地添加加密/限制。

【讨论】：