测验：工作负载安全

信任域是 cluster.local，prod 命名空间中 service account checkout 显示的 pod 的 SPIFFE ID 是多少？

• spiffe://cluster.local/prod/checkout
• spiffe://prod/sa/checkout
• spiffe://cluster.local/ns/prod/sa/checkout
• spiffe://cluster.local/pod/prod/checkout

我们向迄今为止没有授权策略的工作负载添加了 ALLOW 策略。不符合该政策的现有流量怎么办？

• 它按原样被允许 - 因为 ALLOW 策略仅添加权限。
• 拒绝 — 因为一旦存在 ALLOW 策略，工作负载就处于白名单模式。
• 仅保留并允许警告日志。
• DENY策略必须一起才能被拒绝

当我在 PERMISSIVE 状态下应用principals条件的 ALLOW 策略时，所有请求都会导致 403。最可能的原因是什么？

• 在 PERMISSIVE 模式下不评估 AuthorizationPolicy
• 主体只能在命名空间的基础上使用
• 在以纯文本形式传入的请求中，主体为空并且与主体条件不匹配。
• 如果 RequestAuthentication 不存在，则不会填充主体。

PeerAuthentication 对于整个网格来说是 STRICT，对于支付命名空间是 PERMISSIVE，对于支付中的遗留工作负载是 DISABLE。哪些模式适用于遗留工作负载？

• 禁用
• 严格的
• 宽容
• 政策因冲突而被忽视

我使用 RequestAuthentication 设置 JWT 验证。如何处理没有令牌的请求？

• 被 401 拒绝
• 发行者填充默认值和通行证
• 已接受，但被视为未经身份验证的请求
• jwksUri 搜索失败导致 503

即使工作负载证书每 24 小时更新一次，为什么也不需要耗尽连接或重新启动 Pod？

• 这是因为您将证书挂载为文件，并且 kubelet 会自动更新它。
• 这是因为 Envoy 在宽限期内继续使用过期的证书。
• 这是因为 istiod 终止了 TLS。
• 这是因为 istio-agent 通过 SDS 将证书传递给 Envoy，因此无需重新启动进程即可替换证书。

在允许订单身份 POST /v1/charges 的策略中，单独添加了 ALLOW，该策略仅允许同一目标的 JWT 主题。为什么没有 JWT 的订单仍能顺利通过？

• ALLOW 是联合体，因此即使存在现有订单条件，它们也会通过，并且有必要组合 JWT No DENY 等规则的条件。
• ALLOW是交集，但是前面的策略创建时间很快，所以省略了JWT条件，所以创建顺序必须颠倒过来。
• RequestAuthentication 仅验证第一个请求，因此您必须清除证书和会话缓存并再次请求。
• 由于两种类型的身份不能在同一源中使用，因此必须将 JWT 接受策略移至不同的命名空间。