[zh] sync files in /security/authorization/ (#13361)

This commit is contained in:
Michael 2023-06-14 14:52:17 +08:00 committed by GitHub
parent f7b2fd3873
commit ab833f12c1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 51 additions and 49 deletions

View File

@ -20,8 +20,8 @@ test: yes
* 部署工作负载:
该任务使用 `httpbin``sleep` 这两个工作负载,部署在一个命名空间 `foo`
这两个工作负载在每个工作负载前都有一个 Envoy 代理。使用以下命令部署示例命名空间和工作负载:
该任务使用 `httpbin``sleep` 这两个工作负载,部署在一个命名空间 `foo`
这两个工作负载之前都运行了一个 Envoy 代理。使用以下命令部署示例命名空间和工作负载:
{{< text bash >}}
$ kubectl create ns foo
@ -142,7 +142,8 @@ test: yes
EOF
{{< /text >}}
1. 检查 `/ip` 中 HTTP 头中 `x-token: guest``GET` 请求会否被 `deny-method-get` 策略拒绝。“拒绝策略”优先级高于“允许策略”:
1. 检查 `/ip` 中 HTTP 头中 `x-token: guest``GET` 请求会否被 `deny-method-get`
策略拒绝。“拒绝策略”优先级高于“允许策略”:
{{< text bash >}}
$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -X GET -H "x-token: guest" -s -o /dev/null -w "%{http_code}\n"
@ -156,7 +157,8 @@ test: yes
200
{{< /text >}}
1. 检查 `/get` 路径的 HTTP 头 `x-token: admin``GET` 请求是否被拒绝,因为它们与 `allow-path-ip` 策略不匹配:
1. 检查 `/get` 路径的 HTTP 头 `x-token: admin``GET` 请求是否被拒绝,
因为它们与 `allow-path-ip` 策略不匹配:
{{< text bash >}}
$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: admin" -s -o /dev/null -w "%{http_code}\n"
@ -165,8 +167,8 @@ test: yes
## 清理{#clean-up}
1. 从配置中删除命名空间 foo
从配置中删除命名空间 foo
{{< text bash >}}
$ kubectl delete namespace foo
{{< /text >}}
{{< text bash >}}
$ kubectl delete namespace foo
{{< /text >}}

View File

@ -16,7 +16,7 @@ status: Alpha
模拟运行注解允许您在生产流量上应用授权策略之前更好地理解其效果,
从而帮助减少由于不正确的授权策略引起的生产流量中断风险。
## 开始之前{#before-you-begin}
## 开始之前 {#before-you-begin}
在开始本任务之前,请完成以下操作:
@ -63,7 +63,7 @@ status: Alpha
因为缓存和传播开销可能会导致某些延迟。
{{< /warning >}}
## 创建模拟运行策略{#create-dry-run-policy}
## 创建模拟运行策略 {#create-dry-run-policy}
1. 使用以下命令创建带有模拟运行注解 `"istio.io/dry-run": "true"` 的授权策略:
@ -105,23 +105,23 @@ status: Alpha
...
{{< /text >}}
## 在代理日志中检查模拟运行结果{#check-dry-run-results-in-proxy-log}
## 在代理日志中检查模拟运行结果 {#check-dry-run-results-in-proxy-log}
1. 模拟运行结果可以在代理调试日志中找到,格式为
`shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]`
运行以下命令检查日志:
模拟运行结果可以在代理调试日志中找到,格式为
`shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]`
运行以下命令检查日志:
{{< text bash >}}
$ kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo | grep "shadow denied"
2021-11-19T20:20:48.733099Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:21:45.502199Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:22:33.065348Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
...
{{< /text >}}
{{< text bash >}}
$ kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo | grep "shadow denied"
2021-11-19T20:20:48.733099Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:21:45.502199Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:22:33.065348Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
...
{{< /text >}}
另见[故障排查指南](/zh/docs/ops/common-problems/security-issues/#ensure-proxies-enforce-policies-correctly)了解日志记录更多细节。
另见[故障排查指南](/zh/docs/ops/common-problems/security-issues/#ensure-proxies-enforce-policies-correctly)了解日志记录更多细节。
## 使用 Prometheus 检查指标中的模拟运行结果{#check-dry-run-result-in-metric-using-prometheus}
## 使用 Prometheus 检查指标中的模拟运行结果 {#check-dry-run-result-in-metric-using-prometheus}
1. 使用以下命令打开 Prometheus 仪表板:
@ -149,7 +149,7 @@ status: Alpha
{{< image width="100%" link="./prometheus.png" caption="Prometheus dashboard" >}}
## 使用 Zipkin 检查追踪中的模拟运行结果{#check-dry-run-result-in-tracing-using-zipkin}
## 使用 Zipkin 检查追踪中的模拟运行结果 {#check-dry-run-result-in-tracing-using-zipkin}
1. 使用以下命令打开 Zipkin 仪表板:
@ -157,7 +157,7 @@ status: Alpha
$ istioctl dashboard zipkin
{{< /text >}}
1. 查找从 `sleep``httpbin` 到请求到追踪结果。
1. 查找从 `sleep``httpbin` 的请求的追踪结果。
如果您由于 Zipkin 中的延迟看到追踪结果,请尝试发送更多请求。
1. 在追踪结果中,您应看到以下自定义标记,表明此请求被命名空间 `foo` 中的模拟运行策略 `deny-path-headers` 拒绝:
@ -171,7 +171,7 @@ status: Alpha
{{< image width="100%" link="./trace.png" caption="Zipkin dashboard" >}}
## 总结{#summary}
## 总结 {#summary}
代理调试日志、Prometheus 指标和 Zipkin 追踪结果表明模拟运行策略将拒绝请求。
如果模拟运行结果不符预期,您可以进一步更改策略。
@ -184,7 +184,7 @@ status: Alpha
* 将模拟运行注解的值更改为 `false`
## 限制{#limiatations}
## 限制 {#limiatations}
模拟运行注解目前处于实验阶段,具有以下限制:
@ -195,7 +195,7 @@ status: Alpha
* 代理日志、指标和追踪中的模拟运行结果仅用于手动故障排除,并且不应用作 API因为它可能随时更改而没有事先通知。
## 清理{#clean-up}
## 清理 {#clean-up}
1. 从您的配置中移除命名空间 `foo`

View File

@ -16,7 +16,7 @@ test: yes
在开始此任务之前,请执行以下操作:
* 阅读了[Istio 授权概念](/zh/docs/concepts/security/#authorization)。
* 阅读了 [Istio 授权概念](/zh/docs/concepts/security/#authorization)。
* 遵照 [Istio 安装指南](/zh/docs/setup/install/istioctl/)安装完成 Istio 并启用了双向 TLS。
@ -186,12 +186,12 @@ test: yes
## 清除 {#clean-up}
1. 从您的配置中删除所有的授权策略:
从您的配置中删除所有的授权策略:
{{< text bash >}}
$ kubectl delete authorizationpolicy.security.istio.io/allow-nothing
$ kubectl delete authorizationpolicy.security.istio.io/productpage-viewer
$ kubectl delete authorizationpolicy.security.istio.io/details-viewer
$ kubectl delete authorizationpolicy.security.istio.io/reviews-viewer
$ kubectl delete authorizationpolicy.security.istio.io/ratings-viewer
{{< /text >}}
{{< text bash >}}
$ kubectl delete authorizationpolicy.security.istio.io/allow-nothing
$ kubectl delete authorizationpolicy.security.istio.io/productpage-viewer
$ kubectl delete authorizationpolicy.security.istio.io/details-viewer
$ kubectl delete authorizationpolicy.security.istio.io/reviews-viewer
$ kubectl delete authorizationpolicy.security.istio.io/ratings-viewer
{{< /text >}}

View File

@ -13,7 +13,7 @@ test: yes
本教程向您展示如何通过设置 Istio 授权策略来实现基于 JSON Web TokenJWT的强制访问控制。
Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
## 开始之前
## 开始之前 {#before-you-begin}
在开始这个任务之前,请先完成以下操作:
@ -24,7 +24,7 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
* 参照 [Istio 安装指南](/zh/docs/setup/install/istioctl/)安装 Istio。
* 部署两个工作负载workload`httpbin` 和 `sleep`。将它们部署在同一个命名空间中,
* 例如 `foo`。每个工作负载都在前面运行一个 Envoy 代理。可以使用以下命令来部署它们:
* 例如 `foo`。每个工作负载都在前面运行一个 Envoy 代理。可以使用以下命令来部署它们:
{{< text bash >}}
$ kubectl create ns foo
@ -40,10 +40,10 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
{{< /text >}}
{{< warning >}}
如果没有看到预期的输出,过几秒再试。缓存和策略传播可能造成延迟。
如果没有看到预期的输出,过几秒再试。缓存和策略传播可能造成延迟。
{{< /warning >}}
## 允许包含有效 JWT 和 列表类型声明的请求
## 允许包含有效 JWT 和 列表类型声明的请求 {#allow-requests-with-jwt-and-claims}
1. 以下命令为 `foo` 命名空间下的 `httpbin` 工作负载创建一个名为 `jwt-example`
的身份验证策略。这个策略使得 `httpbin` 工作负载接收 Issuer 为 `testing@secure.istio.io`
@ -51,7 +51,7 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
{{< text bash >}}
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
name: "jwt-example"
@ -87,7 +87,7 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
{{< text syntax="bash" expandlinks="false" >}}
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: require-jwt
@ -130,7 +130,7 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
{{< text syntax="bash" expandlinks="false" >}}
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: require-jwt
@ -175,10 +175,10 @@ Istio 授权策略同时支持字符串类型和列表类型的 JWT 声明。
403
{{< /text >}}
## 清理
## 清理 {#cleanup}
1. 删除 `foo` 命名空间:
删除 `foo` 命名空间:
{{< text bash >}}
$ kubectl delete namespace foo
{{< /text >}}
{{< text bash >}}
$ kubectl delete namespace foo
{{< /text >}}