面向Memcached的Istio精细化授权策略配置咨询

你提出的访问管控目标完全可以通过Istio授权策略实现。你现有配置仅覆盖了「拒绝namespace1以外所有来源请求」的粗粒度规则，缺失namespace1内部的服务级拒绝逻辑，可根据维护场景选择两种配置方案。

方案选型说明 #

• 延续现有DENY策略的扩展逻辑：在原有拒绝规则基础上，追加对namespace1内A、D服务的匹配规则，和现有配置的维护逻辑保持一致
• 推荐采用白名单ALLOW策略：仅放行namespace1内B、C服务的访问请求，其余所有来源（包含跨命名空间、同命名空间未匹配的服务）默认拒绝，不需要叠加多层拒绝规则，后续服务变更时维护成本更低，也不会出现规则漏配导致的权限放行问题

配置参考 #

1. 扩展现有DENY策略的实现 #

在原有yaml配置基础上，追加针对namespace1内A、D服务的拒绝规则即可：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: authorization-policy-deny-all
 namespace: memcached
spec:
 selector:
   matchLabels:
     app: activator
 action: DENY
 rules:
 # 原有规则：拒绝所有非namespace1的来源请求
 - from:
   - source:
       notNamespaces: ["namespace1"]
 # 新增规则：拒绝namespace1内A、D服务的来源请求
 - from:
   - source:
       namespaces: ["namespace1"]
       # 替换为A、D服务对应的ServiceAccount完整SPIFFE身份
       principals:
       - "cluster.local/ns/namespace1/sa/<A服务的ServiceAccount名称>"
       - "cluster.local/ns/namespace1/sa/<D服务的ServiceAccount名称>"

注意：Istio通过工作负载的ServiceAccount签发的SPIFFE身份做请求来源匹配，生产环境建议为每个微服务配置独立ServiceAccount，避免使用default账户导致的身份匹配精度不足问题。若未自定义ServiceAccount，需将上述值替换为对应服务实际关联的身份值。

2. 更易维护的白名单ALLOW策略实现 #

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: memcached-access-allowlist
 namespace: memcached
spec:
 selector:
   matchLabels:
     app: activator
 action: ALLOW
 rules:
 - from:
   - source:
       namespaces: ["namespace1"]
       # 仅放行B、C服务的来源请求
       principals:
       - "cluster.local/ns/namespace1/sa/<B服务的ServiceAccount名称>"
       - "cluster.local/ns/namespace1/sa/<C服务的ServiceAccount名称>"

生效说明：当命名空间内存在ALLOW类型的授权策略时，所有未被规则匹配的请求会被Istio默认拒绝，天然覆盖了「拒绝namespace2流量、拒绝namespace1内A/D服务流量」的管控要求，不需要额外配置兜底拒绝规则。
前提校验：所有参与访问的Pod需开启Istio双向TLS（默认全局安装时自动启用），保证请求中携带可识别的工作负载身份信息，避免规则匹配失效。

内容的提问来源于stack exchange，提问作者user13810982