是否有推荐的方法来使用Kubernetes Secrets？它们可以作为环境变量或使用卷安装公开。一个比另一个安全吗？
答案 0 :(得分：4)
https://www.oreilly.com/library/view/velocity-conference-2017/9781491985335/video316233.html
环境变量公开的Kubernetes机密可以通过/ proc /在主机上枚举。如果是这种情况，则通过卷挂载加载它们可能更安全。
答案 1 :(得分：1)
Secrets默认比environment variables安全，因为它们是加密的，并且比在运行进程的基础环境中公开的环境变量的作用域更窄。
在Kubernetes中，如果我没记错的话，功能肯定仅限于base64编码/解码，因此在实践中它不提供真正的加密即服务。
但是，如果您希望对应用程序的秘密提供更好的安全控制并将其与Kubernetes无缝集成，则绝对应该查看Vault by Hashicorp，我认为这是一个了不起的工具，其主要目的之一是提供尽可能简单的加密即服务，并减少诸如秘密蔓延现象之类的问题。
答案 2 :(得分：1)
安装的机密会自动更新
更新已在卷中使用的机密时，最终也会投影投影的密钥。 Kubelet正在检查是否在每个定期同步中都重新装入已安装的机密。但是，它正在使用其本地缓存来获取Secret的当前值。
在多容器容器中，容器中的每个容器都必须请求其volumeMount中的秘密卷才能在容器中可见。这可用于在Pod级别构造有用的安全分区。
根据上述内容，通过卷装载从官方文档中找到秘密是一个更好的选择。
答案 3 :(得分：1)
我认为安全性没有任何区别。 因为如果一个节点被入侵，他们可以看到秘密。
示例：
---
apiVersion: v1
kind: Secret
metadata:
name: mount
type: Opaque
data:
foo: ""
---
apiVersion: v1
kind: Secret
metadata:
name: env
type: Opaque
data:
BAR: "BAR"
---
apiVersion: v1
kind: Pod
metadata:
name: mount
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
envFrom:
- secretRef:
name: env
volumeMounts:
- name: mount
mountPath: "/opt/mount"
readOnly: true
volumes:
- name: mount
secret:
secretName: mount
$ kubectl exec mount -- ls -la /opt/mount
total 0
drwxrwxrwt 3 root root 100 Jan 8 03:00 .
drwxr-xr-x 1 root root 19 Jan 8 03:00 ..
drwxr-xr-x 2 root root 60 Jan 8 03:00 ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 31 Jan 8 03:00 ..data -> ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 10 Jan 8 03:00 foo -> ..data/foo
$ kubectl exec mount -- env | grep BAR
BAR=
$ docker ps | grep mount
8dbde26864a4 nginx "nginx -g 'daemon of…" 8 minutes ago Up 8 minutes k8s_nginx_mount_default_3438a94b-e4af-41a7-8d85-7668fcbd9928_0
$ docker inspect 8dbde26864a4 | grep -A 1 '"Env"'
"Env": [
"BAR=",
$ docker inspect 8dbde26864a4 | grep '"Source"' | grep mount
"Source": "/var/lib/kubelet/pods/3438a94b-e4af-41a7-8d85-7668fcbd9928/volumes/kubernetes.io~secret/mount"
$ ls -la /var/lib/kubelet/pods/3438a94b-e4af-41a7-8d85-7668fcbd9928/volumes/kubernetes.io~secret/mount
合計 0
drwxrwxrwt 3 root root 100 1月 8 12:00 .
drwxr-xr-x 4 root root 46 1月 8 12:00 ..
drwxr-xr-x 2 root root 60 1月 8 12:00 ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 31 1月 8 12:00 ..data -> ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 10 1月 8 12:00 foo -> ..data/foo
您可以看到秘密设计建议 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/secrets.md
它是这样写的
如果某个节点受到威胁，则唯一可能暴露的秘密应该是属于计划在其上的容器的秘密
所以我认为这个秘密似乎不能保证当一个节点被入侵时对容器秘密的保护。
答案 4 :(得分：0)
我同意TMC的回答，但想为那些正在思考的人添加一个注释，“那12因子呢？”。由于12F似乎要求将配置存储为ENV变量，因此有时会反对使用卷挂式机密。首先，这些是建议性的，自愿的，里程数可变的最佳做法建议。其次，有此部分：
在十二因子应用程序中，环境变量是粒度控件，每个控件都与其他环境变量完全正交。它们从不作为“环境”分组在一起，而是针对每个部署进行独立管理。该模型可以随着应用程序在其生命周期内自然扩展到更多部署而平滑地扩展。
来源：https://12factor.net/config
基本上，结合其余描述，我了解12F Config管理的指导原则是：
在我的拙见中，批量安装的Kubernetes Secrets 可以实现这些目标，具体取决于您创建哪种Secret对象以及如何管理它们。
答案 5 :(得分：0)
kubernetes秘密作为名称，是用于存储敏感数据（例如用户名和密码）的对象。
示例：
kubectl create secret generic cloudsql-user-credentials --from-literal=username=[user] --from-literal=password=[password]
ConfigMaps可用于存储详细信息：属性。 yaml示例：
apiVersion: v1
kind: ConfigMap
metadata:
name: example
namespace: docker4openshift
data:
app.database.name: [instance.db.name]
通常，秘密用于通行证和用户，数据库名称用于配置映射等。
答案 6 :(得分：0)
我也有同样的问题，一直在寻找有关环境变量与体积的确切答案。我什么都找不到，just discussions like these。除了上面DT.所指出的以外，Kuberentes文档也没有解决此问题，甚至还缺少一点。在讨论这里讨论的内容时，我有我的见解，不一定是正确的，只是我已经能够推测的。如果我误会了一些东西，欢迎改正。这是我的理解：