容器内机密的 k8s 管理/处理

Question

我目前正在将我的docker部署迁移到k8s清单，我想知道如何处理秘密。目前，我的docker容器获取/run/secrets/app_secret_key以env-var的形式获取容器内的敏感信息。但与k8s机密处理相比，这有什么好处吗？因为在另一方面，我也可以在我的声明中这样做。yaml：

env:
- name: MYSQL_PASSWORD
  valueFrom:
    secretKeyRef:
      name: mysql-password
      key: password

然后直接将秘密作为env变量放入容器中...我能够注意到的唯一区别是，如果我在容器内提取/run/secrets/app_secret_key，如下所示(docker-entrypoint.sh):

export APP_SECRET_KEY="$(cat /run/secrets/app_secret_key)"

当我在部署后访问容器时，看不到env var，似乎env var只在docker-entrypoint.sh最初被触发的“会话”中可用(在容器/pod启动时)。

所以我现在的问题是，在这里什么更有意义：只需使用上面显示的env:语句，或者在容器中手动获取/run/secrets/app_secret_key。。。

先谢谢你

Answer 1

将secret公开为env var或file只是以k8s方式使用secret的一种方式。

一些机密（如password）只是一行长的字符串，因此将其用作env-var很方便。其他机密（如ssh私钥或TLS证书）可以是多行，这就是为什么您可以将机密装载为卷的原因。

尽管如此，还是建议将您的秘密声明为k8s的秘密资源。这样您就可以通过kubectl获取所需的值，而无需进入容器内部。您还可以制作一个模板，如helm图表，在部署时生成秘密清单。使用RBAC，您还可以控制谁可以读取秘密清单。

根据您的评论，是的，任何可以进入容器内部的用户都将有权访问shell用户可用的资源。

Answer 2

坦率地说，两者都是同一件事不同实现，你可以选择任何一个，但我更喜欢kubernetes approch作为安装秘密，而不是仅仅因为可见性而在运行时读取容器。

如果你寻找一个容器并不重要，但是当我们有30-40个微服务在4-5个环境中运行并且有100甚至200个秘密时。在这种情况下，一个部署出错，我们可以查看部署清单并找出整个应用程序。我们不必搜索docker文件来了解发生了什么。