容器内的 k8s management/handling 个秘密

Question

我目前正在将我的 docker 部署迁移到 k8s 清单，我想知道秘密的处理。目前我的 docker 容器获取 /run/secrets/app_secret_key 以获取容器内的敏感信息作为环境变量。但与 k8s 秘密处理相比，这有什么好处吗？我也可以在我的 manifest.yaml:

中做这样的事情

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

这比直接将秘密作为容器内的环境变量带来... 我能够注意到的唯一区别是，如果我像这样在容器内获取 /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 最初被触发的“会话”中可用（在container/pod 启动）。

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

提前致谢

Answer 1

将秘密公开为 env var 或文件只是以 k8s 方式使用秘密的一种方式。

有些secret比如password就是一行长字符串，作为env var使用比较方便。其他秘密如 ssh 私钥或 TLS 证书可以是多行，这就是为什么你可以将秘密挂载为卷。

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

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

Answer 2

坦率地说，两者都是同一事物的不同实现，您可以选择其中一个，但我更喜欢 kubernetes 方法作为安装秘密，而不是在运行时间读取容器，仅仅是因为可见性。

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

k8s management/handling of secrets inside container