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

Question

我可以轻松获取存储在Kubernetes.

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

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

例子ZXhwb3NlZC1wYXNzd29yZAo=

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

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

Answer 1

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

您编码的数据可能包含许多无法识别的字符、换行符等，因此对它们进行编码很方便。

在 Kubernetes 中，您可以使用此指令启用加密。

但是 kubernetes 不应该是唯一的事实来源，而是 kubernetes 从您需要选择的外部 vault 加载这些秘密，例如hashcorp 的 vault，如评论中所示。

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

• 掌舵的秘密
• 卡姆斯
• 密封的秘密
• git-crypt

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

Answer 2

关键是在 Kubernetes 中，secret 允许您通过控制对 secret 的访问来保护您的密码（您想要通过加密来做的事情），而不是通过对其进行加密。

它有几种机制：

• Secret 只能由其相同命名空间的那些访问。
• 机密具有与任何其他文件一样的权限，因此您可以选择有权访问它的人。
• 它们仅在需要时才发送到 pod ，而不是之前。
• 它们没有写入本地磁盘存储。

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

Answer 3

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

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

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

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