5.2 Secret：上锁的农药柜

本节摘要：Secret 是存放密码、令牌、证书等敏感配置的资源对象，用法与 ConfigMap 几乎一致（环境变量或卷挂载），但多了类型约束与分发限制。必须认清：Secret 的 base64 只是编码不是加密，真正的安全来自最小暴露面与 RBAC 权限（第八章）。本节为书屋保管数据库密码与 TLS 证书，并演练"改密码不惊动无关苗"的标准动作。

农药和肥料为什么要分开存放

上一节结尾立了条纪律：敏感配置不许进 ConfigMap。理由展开讲有两层。第一层是可见面：ConfigMap 的内容对能读田的人完全明文，而 Secret 至少在分发上受限——kubelet 只把它派发给真正需要的节点，台账层面也能配更严的读权限（细节在第八章 RBAC）。第二层是语义：密码要轮换、证书要续期、令牌要吊销，它们的生命周期管理方式与普通配置不同，混放会让"改个开关"的人顺手看见"不该看的钥匙"。

农事的说法更直白：肥料可以露天堆在田头，农药必须锁进柜子、按需取用、用完登记。Secret 就是那口带锁的农药柜。

造一口柜子

Secret 的写法与 ConfigMap 高度同构，最贴心的是 stringData 字段——写明文，系统自动编码：


# 农药柜：数据库口令（stringData 写明文，省去手工编码）
apiVersion: v1
kind: Secret
metadata:
  name: api-db-cred
  namespace: greenlib-prod
type: Opaque                 # 通用柜型
stringData:
  DB_USER: "greenlib_app"
  DB_PASS: "S9!vq2#bookshelf"


kubectl apply -f api-db-secret.yaml
# secret/api-db-cred created

# 看看台账里存的样子（base64 编码）
kubectl get secret api-db-cred -n greenlib-prod -o jsonpath='{.data.DB_PASS}'
# UzkhdnEyI2Jvb2tzaGVsZg==
# 注意：这只是编码，echo 该串加 base64 解码即可还原——它不是加密！

kubectl get secrets -n greenlib-prod
# NAME          TYPE                      DATA   AGE
# api-db-cred   Opaque                    2      30s
# greenlib-tls  kubernetes.io/tls         2      12d   第四章 Ingress 用的证书柜

柜子里的东西怎么用

用法与 ConfigMap 完全同构，把 configMapRef 换成 secretRef、configMap 卷换成 secret 卷即可。书屋接口的播种单加上两行：


# Deployment 节选：口令走环境变量
          envFrom:
            - configMapRef:
                name: api-config
            - secretRef:                 # 换成从农药柜取
                name: api-db-cred

证书类的取用略有不同，走文件挂载（Ingress Controller 就是这么读第四章那口 greenlib-tls 柜的）：


# 证书柜挂载示例（节选）
      volumes:
        - name: tls-certs
          secret:
            secretName: greenlib-tls     # 柜里 cert 与 key 两个文件落入挂载目录


# 验证口令已送达苗的环境变量
kubectl exec -n greenlib-prod deploy/greenlib-api -- sh -c 'echo $DB_USER'
# greenlib_app
# 输出说明了最重要的事实：对应用来说 ConfigMap 与 Secret 毫无差别，都是"门口的配方"

还有一种专门柜型值得认脸：kubernetes.io/dockerconfigjson。苗的图纸若存在私有仓库里，起盆前要先验明正身，这类"拉镜像的凭证"就是用它保管，在播种单的 imagePullSecrets 字段引用。书屋的图纸仓库是公开的，暂时用不上，记住有这口柜即可。

改密码的标准动作

数据库换了口令，怎么让苗跟上？标准动作是"先造新柜，再改引用，最后销毁旧柜"：


# 第一步：造一口新柜（新口令）
kubectl create secret generic api-db-cred-v2 -n greenlib-prod \
  --from-literal=DB_USER=greenlib_app \
  --from-literal=DB_PASS='K7$pz8!tractor'
# secret/api-db-cred-v2 created

# 第二步：改播种单引用（编辑清单里的 secretRef 名字后重新 apply）
kubectl apply -f api-deployment.yaml
# 触发滚动重启，新苗拿着新口令上岗（第七章详述这股"换苗潮"）

# 第三步：确认全部就绪后销毁旧柜
kubectl delete secret api-db-cred -n greenlib-prod
# secret "api-db-cred" deleted

三步的顺序有讲究：先加后减，保证任何时刻都有能开门的柜子；销毁放最后，避免旧苗还在跑、柜子先没了的尴尬窗口。这套"双柜切换"的思路在轮换证书、轮换令牌时同样适用。

把安全边界说透

入门阶段必须建立的正确观念，按重要性排序：

base64 不是加密。Secret 默认只是编码存储，真正拦住人的是 RBAC 权限与网络隔离。要真加密，需要接入密钥管理系统（企业环境的常见配置），入门知道边界即可。
不要把 Secret 提交进代码仓库。清单里的口令应当来自部署流水线的注入，而不是躺在版本库里等泄漏。
最小暴露面：苗只挂自己需要的柜子；人只给自己负责的田授权（第八章 RBAC 兑现这条）。
环境变量里的口令可能被打进崩溃转储或日志，对极敏感场景优先用文件挂载并限制文件权限。

💡 一个朴素但有效的检验：想象台账被整个导出成一份文件，逐条看过去，哪条内容会让你心跳加速？会让心跳加速的，就该在农药柜里，并且要配更严的读取权限。

本节要点回顾

Secret 与 ConfigMap 用法同构，区别在敏感语义、分发限制与类型系统
base64 是编码不是加密，安全靠 RBAC、靠不入库、靠最小暴露面
stringData 写明文最顺手；证书走挂载，口令可走环境变量或挂载
双柜切换三步法：造新柜、改引用、销毁旧柜，顺序不可乱
私有仓库拉镜像凭证是专门柜型 dockerconfigjson，由 imagePullSecrets 引用

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流