测验：mTLS 与授权

Istio 根据什么建立工作负载身份？

• Kubernetes service account
• Pod 所在节点的主机名
• 分配给 Pod 的集群 IP 地址
• Pod 名称与 namespace 的组合

为什么只有 spec: {} 的 AuthorizationPolicy 会造成全面拒绝？

• 因为存在 ALLOW 策略却没有匹配规则，相当于白名单中没有任何对象
• 因为未填写 action 的策略默认会被解释为 DENY，从而阻止所有请求
• 因为没有 selector 的策略会把整个 namespace 设为拒绝目标
• 因为规则为空会被解释为 CUSTOM，并寻找不存在的外部授权服务器

网格全局、namespace 和工作负载三个层级各有 PeerAuthentication 策略时，特定工作负载适用哪一项？

• 网格全局策略
• 工作负载策略
• namespace 策略
• 三个策略的逻辑与

只部署 RequestAuthentication 而不配置 AuthorizationPolicy，没有 JWT 的请求会怎样？

• 由于缺少 AuthorizationPolicy，策略应用会被拒绝
• 因为没有 token，返回 401
• 以未认证状态通过
• 由于不属于授权对象，返回 403

AuthorizationPolicy 的正确评估顺序是什么？

• 按声明顺序
• CUSTOM → DENY → ALLOW
• ALLOW → DENY → CUSTOM
• DENY → ALLOW → CUSTOM

在 PERMISSIVE 状态下，为什么明文传入的请求无法匹配 principals 条件？

• 因为 principal 来自 mTLS 证书，而明文连接没有证书
• 因为对于明文请求，代理会删除所有携带身份的请求头
• 因为在 PERMISSIVE 模式下，授权评估会被完全跳过
• 因为无证书请求在规则评估前就被归类为 DENY

在生产网格中启用默认拒绝策略前，最恰当的步骤是什么？

• 先通过 AUDIT action 或 dry-run 观察“如果启用，会拒绝哪些请求”
• 新建 namespace，只在其中部署策略，然后比较结果
• 在流量最少的夜间应用，发现问题时立即回滚
• 增加所有服务的重试次数，以吸收临时拒绝