📚 课程目录第1章 Secrets治理工程导入

1. Secrets治理工程导入

在Kubernetes里，Secret常被当作“存密码的地方”。这个理解不算错，但远远不够。Secret是API Server中的一类命名空间级资源，它把敏感数据以键值对形式保存，并通过挂载卷、环境变量或镜像拉取凭据等方式交付给Pod。它真正的工程意义在于：它是集群内敏感数据的分发平面，连接着身份、工作负载、外部密钥系统和审计体系。一旦把它只当配置项，治理问题就会在规模化后集中爆发。

先看本质。Secret对象的核心字段包括metadata、type、data和stringData。其中data要求值是Base64编码，stringData允许写明文并由API Server自动编码。需要特别强调：Base64不是加密，只是编码。任何能读取Secret对象的人都能还原明文。因此Secret的安全性不来自编码，而来自RBAC、命名空间隔离、加密存储、准入控制和审计。

apiVersion: v1
kind: Secret
metadata:
  name: db-credential
  namespace: prod
type: Opaque
stringData:
  username: app_rw
  password: S3cure-Example-2024

这段示例描述了一个典型的生产凭据。它看起来简单，但治理挑战恰恰藏在“简单”背后。第一，Secret默认以未加密形式写入etcd，除非启用EncryptionConfiguration或使用KMS插件。第二，Secret的读取权限若被get secrets或list secrets宽泛授予，等于把整个命名空间的敏感数据暴露给该主体。第三，环境变量方式注入的Secret可能被进程、日志或崩溃转储带出。第四，Secret轮换后，已挂载的卷不会自动更新到所有应用，环境变量方式更是必须重启Pod。第五，多集群、多环境、多租户下，Secret容易复制、漂移和失控。

不要把Secret提交到Git仓库，也不要用kubectl get secret -o yaml把Base64值直接贴进工单或聊天记录。Base64可被任何人解码。

这些挑战指向一个共同结论：Secret治理不是“创建对象”的问题，而是“敏感数据全生命周期可控”的问题。工程化目标可以归纳为五条主线：最小权限，即谁能读、谁能写、谁能在哪个命名空间操作；静态加密，即etcd中的数据是否被KMS保护；安全交付，即用卷挂载替代环境变量、控制文件权限与只读性；可轮换，即凭据变更后应用如何感知并生效；可审计，即谁在何时读取或修改了哪个Secret。这五条主线不是并列口号，而是相互约束：权限越宽，加密和审计的压力越大；交付方式越随意，轮换越难落地。

上图把治理对象、风险、动作和验证结果放在同一条链路上。它提醒我们：Secret治理不是单点配置，而是从数据源到工作负载、从权限到加密、从交付到轮换的连续控制。任何一个环节缺失，都会让“安全”停留在口号层面。

接下来看一个可执行的判断示例。假设生产命名空间prod中有一个Secretdb-credential，我们希望验证三件事：第一，普通开发者不能读取它；第二，etcd中不以明文出现；第三，应用通过卷挂载读取且文件权限为0400。可以用以下命令做最小验证：

# 1. 验证 RBAC：以开发者身份尝试读取
kubectl auth can-i get secret/db-credential -n prod --as=dev-user
# 期望输出：no

# 2. 验证 etcd 加密：直接读取 etcd 中的原始值
ETCDCTL_API=3 etcdctl get /registry/secrets/prod/db-credential \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key
# 期望看到 k8s:enc:kms:v1:... 前缀，而不是明文

# 3. 验证挂载权限：进入 Pod 查看文件
kubectl exec -it app-pod -n prod -- ls -l /etc/db/
# 期望输出：-r-------- 1 root root ... password

这三条验证分别对应权限、加密和交付。它们不是“做完就算”的检查，而是治理闭环的观察点。若第一条返回yes，说明RBAC过宽；若第二条看到明文，说明静态加密未生效；若第三条权限为0644或属主为普通用户，说明交付方式存在泄漏面。判断依据明确，才能把治理从经验变成工程。

教学示例中的命名空间、Secret名称、用户和路径均为合理假设，用于说明验证方法；实际执行时请替换为你的集群对象与证书路径。

本课程后续将沿着这条链路展开：先建立Secret的本质模型与风险清单，再进入RBAC与命名空间边界，随后讨论etcd加密与KMS、卷挂载与文件权限、轮换与审计、外部密钥系统集成，最后落到多集群治理与自动化。每一节都会围绕真实对象、可观察参数和判断依据展开，而不是停留在概念复述。治理工程的起点，是承认Secret不是“配置”，而是需要被持续控制、验证和演进的敏感数据平面。