Kubernetes秘密体积与环境变量

Kubernetes秘密体积与环境变量,kubernetes,environment-variables,docker-volume,kubernetes-security,kubernetes-secrets,Kubernetes,Environment Variables,Docker Volume,Kubernetes Security,Kubernetes Secrets,有推荐的使用方法吗?它们可以作为环境变量公开,也可以使用卷装载。一个比另一个更安全吗? 环境变量暴露的Kubernetes秘密可以通过/proc/在主机上枚举。如果是这种情况,那么通过卷装载来装载它们可能更安全。我同意TMC的回答,但想为那些想“但是12因子呢?”的人补充一点。有时会有人反对使用卷装机密,因为12F似乎要求将配置存储为环境变量。首先,这些都是建议的、自愿的,您的里程可能会因最佳实践建议而异。第二,这一部分: 在12因素应用程序中,环境变量是粒度控制,每个都与其他环境变量完全正交。

有推荐的使用方法吗?它们可以作为环境变量公开,也可以使用卷装载。一个比另一个更安全吗?


环境变量暴露的Kubernetes秘密可以通过/proc/在主机上枚举。如果是这种情况,那么通过卷装载来装载它们可能更安全。

我同意TMC的回答,但想为那些想“但是12因子呢?”的人补充一点。有时会有人反对使用卷装机密,因为12F似乎要求将配置存储为环境变量。首先,这些都是建议的、自愿的,您的里程可能会因最佳实践建议而异。第二,这一部分:

在12因素应用程序中,环境变量是粒度控制,每个都与其他环境变量完全正交。它们从不作为“环境”组合在一起,而是为每个部署单独管理。这是一个随着应用程序在其生命周期内自然扩展为更多部署而平滑扩展的模型

资料来源:

基本上,结合其余的描述,我理解12F配置管理的指导原则是:

  • 将配置保留在源代码之外
  • 能够将配置注入源工件(例如docker容器)
  • 能够对所需的配置值集进行粒度更改

依我拙见,卷装Kubernetes Secrets可以实现这些目标,这取决于您创建的机密对象的类型和管理方式。

卷装机密会自动更新。

  • 当卷中已经使用的秘密被更新时,投影的密钥最终也会被更新。Kubelet正在检查装载的秘密是否在每次定期同步时都是新的。但是,它正在使用其本地缓存获取机密的当前值

  • 在多容器pod中,pod中的每个容器都必须请求其volumeMounts中的秘密卷,以使其在容器中可见。这可以用于在pod级别构造有用的安全分区


从官方文档中的上述发现来看,通过卷装载保密是一个更好的选择。

我认为在安全性方面没有任何区别。 因为如果一个节点被泄露,他们可以看到秘密

例如:

---
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
你可以看到秘密设计方案

是这样写的

如果一个节点被泄露,唯一可能被泄露的秘密应该是属于调度到该节点上的容器的秘密


因此,我认为这个秘密似乎不能保证在节点被破坏时保护容器的秘密。

我也有同样的问题,一直在寻找关于环境变量与卷的明确答案。我什么也找不到。Kuberentes文档也没有解决这个问题,除了上面提到的,甚至还有一点欠缺。针对这里讨论的一些问题,我有自己的观点,这些观点不一定正确,只是我能够猜测到的。如果我误解了什么,我欢迎改正。以下是我的理解:

  • 就像我看不到环境变量和卷/文件之间的安全性有任何区别一样,只要登录到pod就可以轻松访问它们
  • WRT 12因素应用程序,我同意。我认为没有什么区别。在这两种情况下,它们都是机密规范的一部分,而机密规范是信息的来源,无论它是作为文件还是环境变量进行投影。如果需要将代码与配置完全分离,可以将机密规范(和其他规范)放在单独的repo中
  • 秘密是不安全的,除非。正如其他选项所指出的,例如,是可能的
  • $ 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