身份、受众与权限是三个不同的问题
一句话总结
令牌代表谁、可以发送给谁、获准执行什么操作，是三个不同的问题。仅凭解码结果或管理员模拟请求，无法同时回答三者。
为什么需要它
假设发生如下事件：把报告服务使用的令牌发送给 Kubernetes API 后收到 401。有人认为角色缺少权限，建议授予 cluster-admin；另一人认为令牌明天才过期，所以是服务器错误。两人都还没有确认原因。如果令牌面向不同接收者，增加权限也无法解决，只会留下不必要的权限。
本单元的个人 VM 在两个命名空间中各有一个同名 reader 账户。每个账户只能读取自己命名空间中的一个 lesson-policy ConfigMap，数据是 training-only 这一合成字符串。无需敏感秘密即可重现认证与授权的差异，因此没有理由拿真实服务令牌练习。
工作原理
分别观察签发、验证和使用
TokenRequest 是请求签发服务账户凭据。请求包含 audience、期望生存期；如有需要，还包括要绑定对象的名称和 UID。必须确认响应中的实际过期时间，不能假定请求数字总会原样应用。本实验由管理员为教学账户签发令牌。管理员的签发权限与所签发令牌主体读取 ConfigMap 的权限互不相同。
对 JWT 中间部分进行 base64url 解码，可以读取 sub、aud、exp 等声明，但这并未验证签名。读取纸上写的工号，与向签发机构确认身份证真伪不是一回事。不能因为读到了令牌内容就写成验证完成。
TokenReview 用于查询令牌的认证结果。本实验工具通过管理员请求执行检查，但不显示原始令牌，只显示认证与否、audience、username 和 UID。即使结果为 true，也不表示已允许该用户查询 ConfigMap。必须另行发送真实读取请求，才能同时确认角色和绑定的结果。
不在请求中混入另一份身份证明
在使用管理员 kubeconfig 的 kubectl 上只增加一个选项，却称之为服务账户行为，会使实验含糊。本实验的 GET 客户端不使用管理员客户端证书，只使用 Authorization 中的 bearer 令牌。服务器 CA 验证保持启用，不使用重定向或 proxy。凭据被发送到哪个地址，本身就是实验的一部分。
管理员获准执行的 --as 模拟请求对检查 RBAC 很有用，但其中不包含被检查旧令牌的签名、audience 或过期状态。不能把模拟请求成功复用为令牌有效性的证据，这正是本单元的起点。
如何理解 audience 实验
此 VM 的 API 使用 labhub-kcsa-api 作为接收者。指定 labhub-kcsa-report 签发的令牌，在读取该 API 的 ConfigMap 时返回 401。若明确指定报告接收者，用同一令牌进行 TokenReview，认证结果则为 true。令牌本身并未完全损坏，变化的是把它提交给了哪个接收者。这是本单元通过真实 k3s 探针确认的结果。
这是一个假定存在外部报告服务的示例，本实验并未部署报告服务器。真实服务应在服务器配置中确定允许的 audience，并按该范围检查。无条件接受请求者所给 audience，会失去区分接收者的意义。
实际现场中的情况
先确认请求地址与凭据类型，再看接收者、过期时间和认证结果。认证成功后，再检查目标资源、动词、命名空间和 RBAC。不要断定所有 403 都有同一原因，应同时记录响应原因和请求主体。匿名请求也不一定总是 401，因此不能把本实验错误 bearer 的观察推广到所有请求。
把 Pod 和 SA 的 automountServiceAccountToken 设为 false，是避免自动挂载令牌的设置，并不会取消管理员的 TokenRequest 签发权限。本实验 Pod 关闭自动挂载，并明确签发令牌，以免混淆两种效果。普通 projected token 会由 kubelet 轮换，但本实验保存为文件的令牌不会由 kubelet 代为更新。运营时必须区分两种传递方式。
与下一课的联系
下一篇将讨论账户重建后 UID 改变的情况。随后实验以“自己的资源 200、其他团队资源 403”为基线，比较提交不同 audience 令牌时的 401 与 TokenReview 结果。不要把原始令牌粘贴到终端、报告或公告板。只记录声明和哈希，并标明每项观察属于解码、认证还是授权。