测验：ServiceAccount 与令牌

从 Kubernetes 1.24 起，创建 ServiceAccount 后为什么不再自动生成 Secret？

• 为了从永久有效的长期令牌改用有明确有效期的令牌
• 因为每个 SA 都创建 Secret 会大幅增加 etcd 容量
• 因为创建 RBAC 绑定后才会自动颁发令牌
• 因为 Secret 资源在 v1.24 中已废弃

给令牌指定 audience 的目的是什么？

• 从签名载荷中删去无用声明，缩短令牌
• 使令牌只对指定目标有效，阻止在其他地方重用
• 代替 expirationSeconds 延长有效期
• 自动附加与 aud 值对应的 ClusterRole

设置 automountServiceAccountToken: false 的首要原因是什么？

• NetworkPolicy 根据是否挂载令牌判定出站流量
• 减少 projected 卷挂载，提升 Pod 启动速度
• 让不调用 API 的工作负载没有可被窃取并利用的凭据
• 这样可以完全省略 ServiceAccount 设置

如果没有为 Pod 指定 ServiceAccount，会发生什么？

• 以 system:anonymous 身份调用 API
• 使用该命名空间的 default 账户，多个 Pod 共用同一身份
• 自动分配具有 cluster-admin 权限的账户
• 在 admission 阶段被拒绝，Pod 无法启动

手动创建 kubernetes.io/service-account-token 类型的 Secret，最大的风险是什么？

• 它不是 projected 卷，因此无法挂载到 Pod
• 令牌没有 aud，所以 RBAC 授权不会生效
• 每次更新令牌都会在 etcd 中增加一个新版本
• 令牌不会过期，一旦泄露会一直有效，必须人工撤销

要从 TokenRequest 令牌的载荷中确认主体，应查看哪个声明？

• iss
• aud
• jti
• sub

挂载到 Pod 中的令牌到期后，应用应该怎么做？

• 删除并重新创建 Pod 才能获取新令牌
• kubelet 会更新令牌，重新读取令牌文件即可
• 必须直接调用 TokenRequest 获取并替换令牌
• projected 令牌不会过期，无需处理