测验：集群加固

RBAC 基本上可以防止权限升级。哪些动词组合可以明确绕过此保护？

• 升级、绑定、冒充
• 获取、列出、观看
• 创建、更新、修补
• 删除、删除集合、代理

在 Pod 规范中输入 automountServiceAccountToken: false，true 设置为 Pod 使用的 ServiceAccount。结果如何？

• 令牌已安装（ServiceAccount 设置优先）
• 令牌未挂载（Pod 配置优先）
• API 服务器崩溃并拒绝创建 pod
• kubelet 安装在两个位置

为什么system:masters组织特别危险？

• 审计很困难，因为只能访问 kube-system 命名空间。
• 完全绕过 RBAC 授权检查
• 未记录在审核日志中
• 令牌有效期固定为 24 小时

如何直接询问API服务器特定的ServiceAccount实际上可以做什么？

• 使用 kubectl describe serviceaccount 查看绑定列表
• 使用 kubectl get rolebinding -A 调查所有内容
• 在审核日志中搜索相关 SA 的过去请求。
• kubectl auth can-i <动词> <资源> --as=system:serviceaccount::

手动创建的 kubernetes.io/service-account-token 类型 Secret 比 TokenRequest 方法更危险的最大原因是什么？

• 没有有效期，因此一旦泄露，就永远有效。
• 它仅使用 Base64 进行编码，因此与纯文本没有区别。
• 可以在命名空间之外使用
• kubelet 不会自动旋转

ValidatingWebhook 注册为 failurePolicy：失败，并且所有 Webhook 服务器 Pod 均已死亡。会发生什么？

• 所有符合 webhook 规则的资源创建和修改都会被拒绝。
• 仅跳过策略验证并正常处理请求。
• API服务器自动将failurePolicy降低为Ignore
• 只有该命名空间变为只读。