把零信任策略垒起来

目标

按照顺序依次积累mTLS强制和授权政策，通过宣言掌握评估顺序（CUSTOM → DENY → ALLOW）和“只要有一个ALLOW就会被视为基本拒绝”的性质。

为什么重要

推送安全引入失败的原因几乎总是因为总是跳过顺序。如果不整理普通文本出发地，打开STRICT的话，没有旁车客户端就会立即断开，如果在不知道呼叫图的情况下安装默认拒绝，就会不知道该打开什么而出现故障。

特别是有一个容易忘记的事实。principals因为来自mTLS证书，所以PERMISSIVE状态的明文请求中principal为空，那么就不会匹配任何principal条件。“政策显然正确，但403”是最常见的原因。所以这个练习按照mTLS→基本拒绝→最小权限→安全网→最终用户认证的顺序进行。

这个实践是基于kwok的API对象·manifest设计实践。Kubernetes对象存储在API中，但实际的payments容器·Envoy·JWT验证服务器并没有运行。Istio政策是/root/ica-security/用下面的文件填写，不评分HTTP响应或加密动作。不会连接到示例IdP地址。

第8步是保持现有ALLOW，对8080端口的无JWT请求应用DENY的设计。单独的JWT ALLOW不是两个条件的AND，而是创建允许路径的OR，所以不使用。不是保证其他端口的JWT强制化或允许计数访问的政策。

阶段

1. 名称空间ica-security制作并贴标签istio-injection=enabled请粘上。
2. 名称空间ica-security服务账户payments-api哇orders-api请制作。
3. 在同一个命名空间部署payments-api请分发。垫子标签是app=payments-api，serviceAccountName银payments-api，图像是nginx:1.27-alpine是。还有服务payments-api作为端口8080（名字http)和9090（名字http-metrics)请做两个。
4. /root/ica-security/pa-mesh.yaml请填写PeerAuthentication。 名字default，名称空间istio-system，mtls.mode: STRICT因此不加selector。接着/root/ica-security/pa-workload.yaml在命名空间ica-security，selectorapp: payments-api，mtls.mode: STRICT同时portLevelMtls罗波特9090万PERMISSIVE请填写人政策。
5. /root/ica-security/ap-deny-all.yaml请填写AuthorizationPolicy。 名字default-deny，名称空间ica-security，spec是空着的对象。
6. /root/ica-security/ap-allow-orders.yaml请填写AuthorizationPolicy。selectorapp: payments-api，action: ALLOW并且在一个规则上from.source.principals是cluster.local/ns/ica-security/sa/orders-api，to.operation.methods是POST，to.operation.paths是/v1/charges是。
7. /root/ica-security/ap-deny-admin.yaml请填写AuthorizationPolicy。selectorapp: payments-api，action: DENY，规则是to.operation.paths在/admin/*只有一个，不加from。metadata.annotations在istio.io/dry-run: "true"请粘上。
8. /root/ica-security/ra-jwt.yaml请填写RequestAuthentication。 名字payments-api-jwt，名称空间ica-security，selectorapp: payments-api，jwtRules是一样的，issuerhttps://idp.example.com/，jwksUrihttps://idp.example.com/.well-known/jwks.json，audiences[payments-api]是。接着/root/ica-security/ap-require-jwt.yamlE名字require-jwt，相同的命名空间·selector，action: DENY请填写AuthorizationPolicy。规则一个from.source.notRequestPrincipals是["*"]，相同规则的to.operation.ports是["8080"]是。不添加additional from·to·rules条件和dry-run。请保持6级最低权限ALLOW不变。

参考

• SPIFFE IDprincipals在用的时候spiffe://省略前缀cluster.local/ns/.../sa/...用形状写。
• notRequestPrincipals: ["*"]选择没有经过验证的JWT主体请求。DENY比ALLOW先被评估。
• 使用DENY中的HTTP属性时，TCP请求中缺少的属性也可以匹配。这个任务限制目标端口为8080。
• 在同一个source中同时放置principals和requestPrincipals也是有效的AND设计。请注意与根据不同的ALLOW政策进行分组不同。
• 常见的错误1：在创建基本拒绝时spec削弱关键因素本身。那样的话，政策就不会被按照意图解释。
• 常见的错误2：在Message全域PeerAuthentication上附加selector。那一刻不是全域，而是工作负载策略。
• dry-run 注释值是字符串"true"是。不带引号使用的话会变成布尔值，违反了注释规则。

创建安全实习命名空间

名称空间ica-security制作并贴标签istio-injection=enabled请粘上。

如果没有侧卡，就无法进行mTLS或INGA。请贴上自动注入标签。

根据工作负载创建专用服务账户

名称空间ica-security服务账户payments-api哇orders-api请制作。

SPIFFE ID的最后一个格子是服务账户。如果多个工作负载共享默认值，则无法通过政策区分彼此。

附有服务账户的工作负载部署

在同一个命名空间部署payments-api请分发。垫子标签是app=payments-api，serviceAccountName银payments-api，图像是nginx:1.27-alpine是。还有服务payments-api作为端口8080（名字http)和9090（名字http-metrics)请做两个。

必须在Pad规格中指定serviceAccountName才能发给该身份的证书。请同时打开应用程序端口和计量端口。

消息全域STRICT和端口例外

/root/ica-security/pa-mesh.yaml请填写PeerAuthentication。 名字default，名称空间istio-system，mtls.mode: STRICT因此不加selector。接着/root/ica-security/pa-workload.yaml在命名空间ica-security，selectorapp: payments-api，mtls.mode: STRICT同时portLevelMtls罗波特9090万PERMISSIVE请填写人政策。

消息全域性政策以根命名空间中规定的名称保留，不附加selector。一旦附加selector，就成为工作负载政策。请将例外端口指定为portLevelMtls。

创建基本拒绝命名空间

/root/ica-security/ap-deny-all.yaml请填写AuthorizationPolicy。 名字default-deny，名称空间ica-security，spec是空着的对象。

没有任何规则的ALLOW政策即将全面拒绝。除了spec字段本身外，不能删除，必须保持为空状态。

只按照呼叫图打开

/root/ica-security/ap-allow-orders.yaml请填写AuthorizationPolicy。selectorapp: payments-api，action: ALLOW并且在一个规则上from.source.principals是cluster.local/ns/ica-security/sa/orders-api，to.operation.methods是POST，to.operation.paths是/v1/charges是。

principals是从信任域开始的路径格式。方法和路径都包含在to.operation下。在这个阶段只使用服务帐户条件。

将管理路径再多一层设置为DENY

/root/ica-security/ap-deny-admin.yaml请填写AuthorizationPolicy。selectorapp: payments-api，action: DENY，规则是to.operation.paths在/admin/*只有一个，不加from。metadata.annotations在istio.io/dry-run: "true"请粘上。

DENY比ALLOW先被评价，所以成为抵御ALLOW错误的安全网。因为不管出发地如何，都要阻止，所以不要放from。因为是上报运营前的阶段，所以也附上了影子评价注释。

最终用户令牌强制化

/root/ica-security/ra-jwt.yaml请填写RequestAuthentication。 名字payments-api-jwt，名称空间ica-security，selectorapp: payments-api，jwtRules是一样的，issuerhttps://idp.example.com/，jwksUrihttps://idp.example.com/.well-known/jwks.json，audiences[payments-api]是。接着/root/ica-security/ap-require-jwt.yamlE名字require-jwt，相同的命名空间·selector，action: DENY请填写AuthorizationPolicy。规则一个from.source.notRequestPrincipals是["*"]，相同规则的to.operation.ports是["8080"]是。不添加additional from·to·rules条件和dry-run。请保持6级最低权限ALLOW不变。

RequestAuthentication是令牌验证。单独的ALLOW将与现有允许合并，因此不是必需的。首先将没有JWT主体的请求拒绝为DENY，并限制目标端口为字符串8080。