Question

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

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

然后将秘密作为环境变量直接带入容器... 我能够注意到的唯一区别是，如果我像这样（docker-entrypoint.sh）在容器内获取/ run / secrets / app_secret_key：

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

部署后访问容器时，env var不可见，看来env var仅在docker-entrypoint.sh最初被触发的“会话”（在容器/容器启动时）可用。 >

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

预先感谢

Answer 1

坦率地说，两者都是同一事物的不同实现，您可以选择其中之一，但是由于可见性，我宁愿将kubernetes方法作为安装秘密而不是在运行时读取容器。

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

Answer 2

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

诸如密码之类的秘密只是一个单行长的字符串，因此将其用作env var很方便。诸如ssh私钥或TLS证书之类的其他机密可以是多行，这就是为什么您可以将机密作为卷挂载的原因。

仍然，建议将您的秘密声明为k8的秘密资源。这样，您就可以通过kubectl获取所需的值，而不必进入容器内部。您还可以制作类似头盔图的模板，以在部署时生成秘密清单。使用RBAC，您还可以控制谁可以读取机密清单。

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

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

2 个答案: