Secret 管理

上一章的 ConfigMap 明文存配置。可密码、令牌、密钥这种东西，放明文里太危险。Kubernetes 给了专门的对象叫 Secret（保密字典），专门存少量敏感数据。

它跟 ConfigMap 长得几乎一样，用法也类似。区别是它的定位是”机密”，系统对它多了一些保护动作。但请记住一句话：Secret 不是保险箱，它只是把敏感数据从镜像和 Pod 定义里剥离开。

33-1 Secret 的类型

创建 Secret 时可以用 type 字段声明类型。不写的话默认是 Opaque，也就是”用户自定义的任意数据”。

kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password='S!B*d$zDsb='

这个 generic 子命令生成的正是 Opaque 类型。除它之外，Kubernetes 还内置了几种专用类型：

• kubernetes.io/tls：存证书和私钥，常给 Ingress 用。
• kubernetes.io/dockerconfigjson：从私有镜像仓库拉镜像的凭据。
• kubernetes.io/basic-auth：基础认证的账号密码。
• kubernetes.io/ssh-auth：SSH 私钥。
• kubernetes.io/service-account-token：服务账号令牌（v1.22 后推荐改用短令牌）。

33-2 Base64 不是加密

很多人看到 Secret 里的数据是一串乱码，就以为加密了。其实那是 Base64 编码，谁来都能解码回来。

kubectl get secret db-secret -o jsonpath='{.data.password}' | base64 -d

上面这行命令就能把密码还原成明文。所以 Base64 只是为了让二进制能塞进 JSON，它不提供保密性。

真正想保密，得做两件事：给 etcd 开静态加密，再用 RBAC 把访问权限收到最小。还有，默认情况下 Secret 以明文存在 etcd 里，任何有 API 权限的人都能读。这一点务必放在心上。

33-3 用环境变量注入

跟 ConfigMap 几乎一模一样，只是把 configMapKeyRef 换成 secretKeyRef：

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

33-4 用卷挂载注入

更推荐的方式是挂成卷。Secret 里的每个键变成挂载目录下的一个文件：

volumes:
- name: secret-volume
  secret:
    secretName: db-secret
containers:
- name: app
  image: myapp
  volumeMounts:
  - name: secret-volume
    readOnly: true
    mountPath: "/etc/secret"

挂成卷有两个好处。一是更新会自动传播到容器（同样有同步延迟，且 subPath 方式收不到更新）。二是 kubelet 把 Secret 内容放进了节点的 tmpfs 内存文件系统，Pod 删除后本地副本也跟着清掉，不会落盘到持久存储。

Secret 还有一个贴心细节：只有节点上真有 Pod 需要某个 Secret 时，这个 Secret 才会被发到那个节点。同节点其他 Pod 看不到它。

33-5 不可变 Secret 与安全小结

Secret 也支持 immutable: true，设了之后数据不可改，只能删了重建。对大规模集群，这能减轻 API 服务器负担，也防误改。

最后小结一下安全使用的几条原则：

1. 给 etcd 启用静态加密，别让 Secret 明文躺在存储里。
2. 用 RBAC 限定谁能读、谁能列 Secret，别给宽泛权限。
3. 公共镜像的拉取凭据、证书这类，尽量用对应专用类型。
4. 机密量特别大或要求很高时，考虑 external secret store 这类外部方案。