一个 46 字符的 SA Token 读到了生产数据库密码：K8s RBAC 默认绑定与最小权限加固实战

一、现象：一条 kubectl 命令暴露了 3 个命名空间的数据库密码

去年 9 月，安全团队做一次内部红蓝对抗演练。蓝队（我们）的 payment-service 跑在 prod-payment 命名空间，部署了 4 个 Pod（Kubernetes 1.27.4，EKS 托管，节点 OS 为 Amazon Linux 2）。红队拿到一个测试环境 Pod 后，用 kubectl auth can-i list secrets --namespace prod-payment 试探——返回 yes。

30 秒内，他们 kubectl get secret db-credentials -n prod-payment -o jsonpath='{.data.password}' | base64 -d 拿到了生产 PostgreSQL 15.2 的密码，连接串里还带 host 10.42.3.17:5432 和库名 payment_prod。从拿到 token 到 RDS 控制台看到异常连接，全程 4 分 12 秒。

事后审计发现：3 个命名空间（prod-payment、prod-inventory、staging-analytics）的 ServiceAccount 都绑定了 cluster-admin 或自定义的 secret-reader ClusterRole，其中 secret-reader 的 rules 写的是 apiGroups: [""]、resources: ["secrets"]、verbs: ["get","list"]——没有 resourceNames 限定，等于"所有命名空间所有 Secret 可读"。

二、根因：K8s 的「默认绑定」机制 + 一条看似无害的 cluster-admin

从现象倒推，问题有三层：

1）默认 ServiceAccount 绑定是隐式的。 如果你在 Deployment YAML 里没有显式写 serviceAccountName，K8s 会自动绑到该命名空间的 default SA。更危险的是，很多团队为了"省事"，在 CI/CD 模板里直接写 serviceAccountName: ci-deployer，而这个 SA 的 RBAC 是 cluster-admin——因为当初建这个 SA 的人只想让 CI 能 kubectl apply，顺手给了 cluster-admin，然后再也没人改过。

2）cluster-admin 是真正的"万能钥匙"。 它聚合了 cluster-admin ClusterRole，包含 apiGroups: ["*"]、resources: ["*"]、verbs: ["*"]——不只是 Secret，连 nodes、pods/exec、clusterroles 都能操作。一个拿到这个 SA token 的进程，等同于拿到了集群 root。

3）Token 的 audience 和 expiry 没有收紧。 当时用的是 Kubernetes 1.27 的 legacy token（/var/run/secrets/kubernetes.io/serviceaccount/token），这个 token 没有过期时间，且 audience 默认为 kubernetes.default.svc——任何能读到这个文件的进程都能用它调 API Server。即使 Pod 本身不跑敏感操作，只要它被 pods/exec 或 pods/attach 进入，token 就暴露了。

为什么红队能跨命名空间？ 因为 cluster-admin 是 ClusterRole，不受命名空间隔离约束。secret-reader 虽然名字看起来"只读 Secret"，但绑定的是 ClusterRoleBinding（不是 RoleBinding），同样跨命名空间生效。

三、具体做法：5 步把权限收到"够用就停"

步骤 1：关掉默认 SA 的自动绑定

在每个命名空间的 Deployment 里显式指定 serviceAccountName，并在命名空间级别禁用自动创建：

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: prod-payment
  labels:
    # 这个 label 本身不生效，只是标记；真正的禁用靠 Pod 级
---
# 每个 Pod 必须显式指定
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  namespace: prod-payment
spec:
  template:
    spec:
      automountServiceAccountToken: false   # ← 关键：不自动挂 token
      serviceAccountName: payment-sa        # ← 显式指定

automountServiceAccountToken: false 会让 K8s 不往 Pod 里注入 /var/run/secrets/kubernetes.io/serviceaccount/ 目录——没有 token 文件，就没有 token 可偷。

步骤 2：用 Role + RoleBinding 替代 ClusterRole + ClusterRoleBinding

把 secret-reader ClusterRole 拆成每个命名空间独立的 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payment-secret-reader
  namespace: prod-payment
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["db-credentials"]   # ← 只读这一个 Secret
    verbs: ["get"]                       # ← 只 get，不 list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payment-sa-bind
  namespace: prod-payment
subjects:
  - kind: ServiceAccount
    name: payment-sa
    namespace: prod-payment
roleRef:
  kind: Role
  name: payment-secret-reader
  apiGroup: rbac.authorization.k8s.io

关键区别：resourceNames 限定到具体 Secret 名，verbs 只留 get（不留 list）。这样即使 token 泄露，攻击者只能读 prod-payment/db-credentials 这一个对象，list 被拒，staging-analytics 的 Secret 完全不可见。

步骤 3：给 SA Token 加 audience 和 expiry

Kubernetes 1.20+ 支持 TokenRequest，可以在 Pod spec 里指定：

spec:
  template:
    spec:
      serviceAccountName: payment-sa
      serviceAccountTokenProjection:
        - audience: payment-internal-api   # ← 限定 audience
          expirationSeconds: 3600          # ← 1 小时过期
          path: token

配合 API Server 的 --service-account-issuer=https://kubernetes.default.svc 和 --service-account-signing-key-file，token 变成带 aud 和 exp 的 JWT。拿到 token 的进程如果 audience 不匹配，API Server 直接 401——即使 token 本身是合法的。

步骤 4：用 PodSecurityPolicy / Pod Security Admission 禁掉 pods/exec

K8s 1.25+ 用 Pod Security Admission（PSA）替代了已废弃的 PSP：

# namespace 级别
apiVersion: v1
kind: Namespace
metadata:
  name: prod-payment
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

restricted profile 会拒绝 privileged: true、allowPrivilegeEscalation: true、hostPID/hostNetwork: true 等危险配置。同时，在 RBAC 层面，不要给任何非运维 SA 绑定 pods/exec 权限——这是红队进入 Pod 的最短路径。

步骤 5：审计 + 告警

# 定期跑：列出所有有 secret 读权限的 SA
kubectl auth can-i list secrets --as=system:serviceaccount:prod-payment:payment-sa --namespace=prod-payment
# 期望：yes（仅限 get + resourceNames）

# 审计日志里抓 secret 读取事件
kubectl get events -n prod-payment --field-selector=reason=BackOff
# 配合 CloudTrail / EKS audit log：
# 过滤 verb=list,resource=secrets,namespace=prod-payment,非预期 user

四、踩过的坑与反直觉之处

坑 1：automountServiceAccountToken: false 不是万能的。 如果你的 Pod 里跑了 sidecar（比如 Istio Envoy），Envoy 需要调 API Server 拉配置。关掉 token 注入后 Envoy 直接 crash-loop。解法：给 sidecar 单独一个最小权限 SA，主容器 automountServiceAccountToken: false，sidecar 用 initContainers 或 volumes 显式挂载自己的 token。

坑 2：resourceNames 只对 get 生效，对 list 无效。 如果你写了 verbs: ["get","list"] + resourceNames: ["db-credentials"]，list 依然会返回该命名空间所有 Secret（resourceNames 被忽略）。所以 list 必须显式去掉，或者单独建一个 Role 只给 list 且限定 resourceNames（实际上 list + resourceNames 的组合在 K8s 1.27 里行为不一致，建议直接不用 list）。

坑 3：Token 过期 ≠ 已建立的连接断开。 加了 expirationSeconds: 3600 后，token 过期了，但已经建立的 gRPC / HTTP 长连接不会自动断开——API Server 只在每次请求时校验 token。如果你的客户端用连接池，一个 1 小时前建立的连接在 token 过期后仍能继续用 30 秒（取决于 keep-alive 超时）。所以 token expiry 是"新请求"的防线，不是"存量连接"的防线。

坑 4：kubectl auth can-i 的 --as 参数可以模拟任意 SA，但需要 cluster-admin 权限。 这意味着：如果你用 cluster-admin 账号去审计"其他 SA 能不能读 Secret"，你的权限本身就暴露了——审计账号应该是只读 RBAC 的独立 SA，而不是复用 cluster-admin。

五、结论与可复用清单

核心原则：K8s 的权限模型是"默认全有，再减"，但安全加固应该是"默认全无，再加"。 每次新建 Deployment，先问自己三个问题：

1. 这个 Pod 需不需要调 API Server？不需要 → automountServiceAccountToken: false，结束。
2. 需要 → 它需要哪些资源、哪些 verb？用 Role（不是 ClusterRole）+ resourceNames 精确限定。
3. Token 的 audience 和 expiry 设了没有？设了 → 配合 API Server 的 --service-account-issuer 验证。

可复用检查清单（每次发布前跑一遍）：

# 1. 确认没有 Pod 用 default SA
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.serviceAccountName == null or .spec.serviceAccountName == "default") | .metadata.namespace + "/" + .metadata.name'

# 2. 确认没有 ClusterRoleBinding 绑到非运维 SA
kubectl get clusterrolebindings -o json | jq -r '.items[] | .subjects[] | select(.kind == "ServiceAccount") | .name + " → " + .namespace'

# 3. 确认所有 SA 的 token 都有 expiry
kubectl get pods -A -o json | jq -r '.items[] | .spec.serviceAccountTokenProjection // "none"'

# 4. 确认 secret 读取权限是 Role（非 ClusterRole）
kubectl get rolebindings -A -o json | jq -r '.items[] | select(.roleRef.name | test("secret")) | .metadata.namespace + "/" + .metadata.name'

一句话总结：46 个字符的 token 能读到 3 个命名空间的数据库密码，根因不是 token 太短，而是默认绑定 + cluster-admin + 无 expiry 三连。把这三件事拆开修，每个命名空间的权限面从"全集群所有 Secret"缩到"本命名空间 1 个 Secret 的 get"，攻击面缩小两个数量级。