我目前正在将docker部署迁移到k8s清单，我想知道秘密的处理方法。目前，我的docker容器获取/run/secrets/app_secret_key，以获取容器内的敏感信息作为env var。但与k8s机密处理相比，这有什么好处吗？另一方面，我也可以在我的manifest.yaml:中做这样的事情
env:
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-password
key: password
这比直接将机密作为env变量带入容器。。。我能注意到的唯一区别是，如果我在容器中获取/run/secrets/app_secret_key，就像这样(dockerentrypoint.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。。。
提前感谢
坦率地说，两者都是同一事物的不同实现，你可以选择其中一种，但我更喜欢kubernetes方法作为挂载秘密，而不是仅仅因为可见性而在运行时读取容器。
如果你寻找一个容器并不重要，但当我们有30-40+的微服务在4-5+的环境中运行，并且有大约100甚至200个秘密时。在这种情况下，一个部署出错，我们可以查看部署清单，并找出整个应用程序。我们不必搜索docker文件来了解发生了什么。
将机密公开为env-var或文件只是以k8s方式使用机密的一种方式。
一些类似secret的密码只是一行长的字符串，因此将其用作env var很方便。其他类似ssh私钥或TLS证书的secret可以是多行，这就是为什么您可以将secret作为卷装载。
尽管如此，还是建议将您的秘密声明为k8s秘密资源。这样，您就可以通过kubectl获取所需的值，而无需进入容器。您还可以制作一个类似于helm图表的模板，在部署时生成秘密清单。使用RBAC，您还可以控制谁可以读取机密清单。
根据您的评论，是的，任何可以进入容器的用户都可以访问shell用户可用的资源。