📚 课程目录第2章 AuthorizationPolicy基础

AuthorizationPolicy 基础：YAML 结构解析、action 字段与作用域

AuthorizationPolicy 是 Istio 中实现服务间访问控制的核心资源。理解其 YAML 结构、action 语义以及作用域规则，是后续进行策略回滚与参数调优的前提。本章将拆解 AuthorizationPolicy 的骨架，并重点说明 action 字段与 selector/namespace 的协同机制。

1. AuthorizationPolicy YAML 结构解析

一个标准的 AuthorizationPolicy 资源由以下四个主要部分组成：

字段路径	类型	说明
`metadata.name`	string	策略名称，在命名空间内唯一
`metadata.namespace`	string	策略生效的命名空间（与 selector 配合）
`spec.selector`	map[string]string	标签选择器，匹配目标工作负载
`spec.action`	enum	ALLOW / DENY / CUSTOM / AUDIT
`spec.rules`	array	匹配条件列表（来源、目标、端口、方法等）

以下是一个完整的 AuthorizationPolicy 示例，允许 httpbin 服务被 sleep 服务访问：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-sleep-to-httpbin
  namespace: default
spec:
  selector:
    matchLabels:
      app: httpbin
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/sleep"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/ip"]

关键点：rules 字段是可选的。如果 rules 为空，则 action 会匹配所有请求。这在 DENY 策略中常用于创建全局黑名单。

2. action 字段：ALLOW / DENY / CUSTOM / AUDIT

action 字段决定了策略的最终效果。Istio 支持四种 action，其中 ALLOW 和 DENY 是最常用的两种：

action 值	语义	默认行为（无 rules 时）	典型场景
`ALLOW`	允许匹配的请求	允许所有请求（白名单模式）	显式授权特定服务访问
`DENY`	拒绝匹配的请求	拒绝所有请求（黑名单模式）	封禁恶意来源或敏感路径
`CUSTOM`	委托给外部授权服务	取决于外部服务	对接 OPA、OAuth2 等外部鉴权
`AUDIT`	仅记录日志，不干预请求	记录所有匹配请求	审计合规、灰度验证策略效果

优先级陷阱：当同一工作负载上同时存在 ALLOW 和 DENY 策略时，DENY 策略优先于 ALLOW 策略。这意味着即使某请求匹配了 ALLOW 规则，只要它同时匹配了任何一条 DENY 规则，该请求仍会被拒绝。这是回滚时最容易忽略的隐式冲突。

3. selector 与 namespace 作用域

AuthorizationPolicy 的作用域由 metadata.namespace 和 spec.selector 共同决定。理解两者的组合关系，是避免策略“误伤”或“失效”的关键。

3.1 作用域组合规则

namespace 设置	selector 设置	生效范围	示例
具体命名空间	有标签选择器	仅该命名空间内匹配标签的工作负载	`ns: foo` + `app: bar` → 只影响 foo 命名空间下 app=bar 的 Pod
具体命名空间	空选择器（`{}`）	该命名空间下的所有工作负载	`ns: foo` + 无 selector → 影响 foo 命名空间所有 Pod
`istio-system`	有标签选择器	全集群范围内匹配标签的工作负载	`ns: istio-system` + `app: istio-ingressgateway` → 影响集群所有命名空间中匹配的 Pod
`istio-system`	空选择器	全集群所有工作负载（全局策略）	`ns: istio-system` + 无 selector → 影响整个网格

  最佳实践：生产环境中，建议将全局 DENY 策略部署在 istio-system 命名空间且不设置 selector，作为安全基线；然后在各业务命名空间中使用 ALLOW 策略显式放行合法流量。这种“默认拒绝 + 显式允许”的模式能最大程度减少配置遗漏。

3.2 作用域示意图

下图展示了不同 namespace 与 selector 组合下的策略作用域范围：

4. 实战：selector 与 namespace 的常见误区

误区一：认为 selector 可以跨命名空间匹配。实际上，selector 只能匹配当前策略所在命名空间内的工作负载，除非策略部署在 istio-system。
误区二：在 istio-system 中设置空 selector 后，忘记在业务命名空间中添加 ALLOW 策略，导致全集群所有服务被拒绝。
误区三：多个 ALLOW 策略作用于同一工作负载时，只要任意一条 ALLOW 规则匹配，请求即被允许。这与 DENY 的“一票否决”逻辑相反。

回滚视角：当需要回滚一个 AuthorizationPolicy 时，优先检查其 namespace 和 selector 是否与预期一致。一个常见的回滚场景是：误将全局 DENY 策略的 selector 写错，导致策略未生效；回滚时只需修正 selector 的标签值，而非删除整个策略。