测验：令牌失效与权限撤销

报告受众代币的exp即是未来。发送到指定API时为401，指定报告受众的TokenReview为true。首先要检查什么？

• 检查token的接收者和请求的API接受的接收者是否相同。
• 将所有命名空间的 ConfigMap 读取添加到令牌颁发者的角色中。
• 重新启动颁发令牌的 Pod 并延长现有令牌的过期时间。
• 报告TokenReview成功，因此跳过API的CA验证

清除Role的规则后，同一个token的TokenReview为true，ConfigMap GET为403。从这些结果我们能看出什么呢？

• 令牌无效，但 TokenReview 颁发了新令牌。
• token身份已认证，但读取请求未授权。
• ConfigMap 被删除，API 拒绝创建同名资源。
• SA UID 已更改，但现有绑定恢复了旧令牌

SA 已删除并以相同名称重新创建。过期前，通过现有的RoleBinding，旧令牌为401，新令牌为200。最准确的解释是什么？

• 如果您重复使用该名称，旧令牌将再次有效，但只有第一个请求会被拒绝。
• 这是因为 RoleBinding 会自动将旧 SA UID 替换为新 SA UID。
• 旧 UID 的身份验证将被拒绝，基于名称的绑定也将应用于新身份。
• 新令牌的颁发权限还授予管理员对新令牌的读取权限。

JWT被解码来检查未来的exp，并且管理员--as请求也成功了。为什么旧令牌不足以证明它在当前 API 中有效？

• 这是因为当读取 JWT 的 sub 时，服务器会自动重新创建帐户。
• 这是因为代理请求始终是匿名请求，因此根本不经过实际的 RBAC。
• 这是因为 API 始终使用 RoleBinding 的创建时间而不是过期时间进行身份验证。
• 这是因为解码不是签名验证，并且代理请求不会检查令牌本身。

在此虚拟机中，Pod 和 SA 的 automountServiceAccountToken 设置为 false。但是，管理员通过TokenRequest颁发了令牌。什么是正确的？

• 自动安装设置和管理员的显式令牌颁发权限是单独的控制。
• 如果关闭自动挂载，则会发出，但所有观众验证都将不可避免地失败。
• 如果 Pod 没有挂载，则发出的 token 无法绑定到任何对象。
• 关闭自动挂载后，所有现有 RoleBinding 都将被删除。

就在删除最初调查的RoleBinding之前，同名的对象UID发生了变化。这位实验室助理应该做什么？

• 由于名称和命名空间相同，因此新的 UID 将被忽略并立即删除。
• 停止删除并确定为什么原始调查对象与当前对象不同
• 重复重新创建账户，直至旧UID的TokenReview成功。
• 删除整个命名空间以防止同名对象之间发生混淆。

外部服务离线检查 JWT 签名、颁发者、受众和过期时间。还需要什么来确保合并后的 Pod 仍然存在？

• 只需检查 JWT 中的节点名称不为空即可证明当前 Pod 的存在。
• 只需信任客户端发送的 TokenReview 成功字符串就足够了。
• 您应该使用可信的在线来源（例如 TokenReview）检查当前的绑定状态。
• 无论对象删除如何，将 JWT 中的 exp 更改为服务中的未来内容都是安全的。

最终报告仅列出了旧令牌 401 和新令牌 403。什么观察结果可以支持这样的结论：仅检索预期的绑定而不影响团队的其他成员？

• 整个集群中的 Pod 数量减少，浏览器屏幕呈现绿色。
• 事实上，旧令牌字符串和新令牌字符串的长度不同。
• 结果之一是使用管理员帐户查看整个 ConfigMap 列表。
• 新认证正确·准确删除目标UID·其他团队身份及资源正常 200