mirror of https://github.com/istio/istio.io.git
[zh]improve wasm-module-distribution jwt-route mtls-migration authz-deny (#13037)
Signed-off-by: xin.li <xin.li@daocloud.io>
This commit is contained in:
my-git9
GitHub
parent
30aa8ffe1a
commit
b7ca7f3560
|
|
@ -25,9 +25,12 @@ Istio 通过允许代理动态下载 Wasm 模块来实现这一点。
|
|||
|
||||
## 配置 Wasm 模块{#configure-wasm-modules}
|
||||
|
||||
在这个例子中，您将在您的网格中添加一个 HTTP Basic 身份验证扩展。您将配置 Istio 从远程镜像仓库中提取并加载[基本身份验证模块](https://github.com/istio-ecosystem/wasm-extensions/tree/master/extensions/basic_auth)。该模块将被配置为在调用到 `/productpage` 时运行。
|
||||
在这个例子中，您将在您的网格中添加一个 HTTP Basic 身份验证扩展。
|
||||
您将配置 Istio 从远程镜像仓库中提取并加载[基本身份验证模块](https://github.com/istio-ecosystem/wasm-extensions/tree/master/extensions/basic_auth)。
|
||||
该模块将被配置为在调用到 `/productpage` 时运行。
|
||||
|
||||
为了配置一个具有远程 Wasm 模块的 WebAssembly 过滤器，创建一个 `WasmPlugin` 资源：
|
||||
为了配置一个具有远程 Wasm 模块的 WebAssembly 过滤器，
|
||||
创建一个 `WasmPlugin` 资源：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -55,10 +58,13 @@ EOF
|
|||
{{< /text >}}
|
||||
|
||||
HTTP 过滤器将作为身份验证过滤器注入到入口网关代理中。
|
||||
Istio 代理将解释 `WasmPlugin` 配置，从 OCI 镜像仓库中下载远程 Wasm 模块到本地文件，并通过引用该文件将 HTTP 过滤器注入 Envoy 中。
|
||||
Istio 代理将解释 `WasmPlugin` 配置，从 OCI 镜像仓库中下载远程
|
||||
Wasm 模块到本地文件，并通过引用该文件将 HTTP 过滤器注入 Envoy 中。
|
||||
|
||||
{{< idea >}}
|
||||
如果在 `istio-system` 之外的特定命名空间中创建了 `WasmPlugin`，则该命名空间中的 Pod 将被配置。如果在 `istio-system` 命名空间中创建资源，所有命名空间都会受到影响。
|
||||
如果在 `istio-system` 之外的特定命名空间中创建了 `WasmPlugin`，
|
||||
则该命名空间中的 Pod 将被配置。如果在 `istio-system` 命名空间中创建资源，
|
||||
所有命名空间都会受到影响。
|
||||
{{< /idea >}}
|
||||
|
||||
## 检查配置的 Wasm 模块{#check-the-configured-wasm-module}
|
||||
|
|
@ -77,7 +83,8 @@ Istio 代理将解释 `WasmPlugin` 配置，从 OCI 镜像仓库中下载远程
|
|||
200
|
||||
{{< /text >}}
|
||||
|
||||
关于 `WasmPlugin` API 的更多使用示例，请查看 [API 参考](/zh/docs/reference/config/proxy_extensions/wasm-plugin/)。
|
||||
关于 `WasmPlugin` API 的更多使用示例，请查看
|
||||
[API 参考](/zh/docs/reference/config/proxy_extensions/wasm-plugin/)。
|
||||
|
||||
## 清理 Wasm 模块{#clean-up-wasm-modules}
|
||||
|
||||
|
|
@ -92,15 +99,21 @@ $ kubectl delete wasmplugins.extensions.istio.io -n istio-system basic-auth
|
|||
Istio 代理收集以下统计信息：
|
||||
|
||||
- `istio_agent_wasm_cache_lookup_count`: Wasm 远程获取缓存查找的次数。
|
||||
- `istio_agent_wasm_cache_entries`: Wasm 配置转换和结果的数量，包括成功、没有远程加载、编组失败、远程获取失败和未收到远程获取提示。
|
||||
- `istio_agent_wasm_config_conversion_duration_bucket`: istio-agent 在 Wasm 模块的配置转换上花费的总时间（以毫秒为单位）。
|
||||
- `istio_agent_wasm_remote_fetch_count`: Wasm 远程获取和结果的数量，包括成功、下载失败和校验和不匹配。
|
||||
- `istio_agent_wasm_cache_entries`: Wasm 配置转换和结果的数量，
|
||||
包括成功、没有远程加载、编组失败、远程获取失败和未收到远程获取提示。
|
||||
- `istio_agent_wasm_config_conversion_duration_bucket`: istio-agent
|
||||
在 Wasm 模块的配置转换上花费的总时间（以毫秒为单位）。
|
||||
- `istio_agent_wasm_remote_fetch_count`: Wasm 远程获取和结果的数量，
|
||||
包括成功、下载失败和校验和不匹配。
|
||||
|
||||
如果由于下载失败或其他原因而拒绝了 Wasm 过滤器配置，则 istiod 也会发出带有类型标签 `type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig` 的 `pilot_total_xds_rejects` 。
|
||||
如果由于下载失败或其他原因而拒绝了 Wasm 过滤器配置，
|
||||
则 istiod 也会发出带有类型标签 `type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig`
|
||||
的 `pilot_total_xds_rejects` 。
|
||||
|
||||
## 开发 Wasm 扩展{#develop-a-wasm-extension}
|
||||
|
||||
要了解关于 Wasm 模块开发的更多信息，请参阅 [`istio-ecosystem/wasm-extensions` 存储库](https://github.com/istio-ecosystem/wasm-extensions)中提供的那些指南，
|
||||
要了解关于 Wasm 模块开发的更多信息，请参阅
|
||||
[`istio-ecosystem/wasm-extensions` 存储库](https://github.com/istio-ecosystem/wasm-extensions)中提供的那些指南，
|
||||
这个存储库由 Istio 社区维护，用于开发 Istio 的 Telemetry Wasm 扩展：
|
||||
|
||||
- [使用 C++ 编写、测试、部署和维护 Wasm 扩展](https://github.com/istio-ecosystem/wasm-extensions/blob/master/doc/write-a-wasm-extension-with-cpp.md)
|
||||
|
|
|
|||
|
|
@ -48,7 +48,9 @@ status: Alpha
|
|||
|
||||
## 基于 JWT 声明配置入站路由{#configuring-ingress-routing-based-on-JWT-claims}
|
||||
|
||||
Istio 入口网关支持基于经过身份验证的 JWT 的路由，这对于基于最终用户身份的路由非常有用，并且比使用未经身份验证的 HTTP 属性（例如：路径或消息头）更安全。
|
||||
Istio 入口网关支持基于经过身份验证的 JWT 的路由，
|
||||
这对于基于最终用户身份的路由非常有用，并且比使用未经身份验证的 HTTP
|
||||
属性（例如：路径或消息头）更安全。
|
||||
|
||||
1. 为了基于 JWT 声明进行路由，首先创建请求身份验证以启用 JWT 验证：
|
||||
|
||||
|
|
@ -69,11 +71,14 @@ Istio 入口网关支持基于经过身份验证的 JWT 的路由，这对于基
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
这个请求身份验证将在 Istio 网关上启用 JWT 校验，以便验证过的 JWT 声明稍后可以在虚拟服务中用于路由功能。
|
||||
这个请求身份验证将在 Istio 网关上启用 JWT 校验，以便验证过的
|
||||
JWT 声明稍后可以在虚拟服务中用于路由功能。
|
||||
|
||||
这个请求身份验证只应用于入口网关，因为基于路由的 JWT 声明仅在入口网关上得到支持。
|
||||
|
||||
注意：请求身份验证将只检查请求中是否存在 JWT。要使 JWT 成为必要条件，如果请求中不包含 JWT 的时候就拒绝请求，请应用[任务](/zh/docs/tasks/security/authentication/authn-policy#require-a-valid-token)中指定的授权策略。
|
||||
注意：请求身份验证将只检查请求中是否存在 JWT。要使 JWT 成为必要条件，
|
||||
如果请求中不包含 JWT 的时候就拒绝请求，
|
||||
请应用[任务](/zh/docs/tasks/security/authentication/authn-policy#require-a-valid-token)中指定的授权策略。
|
||||
|
||||
1. 根据经过验证的 JWT 声明将虚拟服务更新到路由：
|
||||
|
||||
|
|
@ -107,7 +112,8 @@ Istio 入口网关支持基于经过身份验证的 JWT 的路由，这对于基
|
|||
虚拟服务使用保留的消息头 `"@request.auth.claims.groups"` 来匹配 JWT 声明中的 `groups` 。
|
||||
前缀的 `@` 表示它与来自 JWT 验证的元数据匹配，而不是与 HTTP 消息头匹配。
|
||||
JWT 支持字符串类型的声明、字符串列表和嵌套声明。使用 `.` 作为嵌套声明名称的分隔符。
|
||||
例如， `"@request.auth.claims.name.givenName"` 匹配嵌套声明 `name` 和 `givenName` 。 当前不支持使用 `.` 字符作为声明名称。
|
||||
例如， `"@request.auth.claims.name.givenName"` 匹配嵌套声明 `name` 和 `givenName`。
|
||||
当前不支持使用 `.` 字符作为声明名称。
|
||||
|
||||
## 基于 JWT 声明验证入口路由{#validating-ingress-routing-based-on-JWT-claims}
|
||||
|
||||
|
|
|
|||
|
|
@ -9,29 +9,38 @@ owner: istio/wg-security-maintainers
|
|||
test: yes
|
||||
---
|
||||
|
||||
本任务阐述如何将 Istio 服务的请求从明文模式平滑过渡至双向 TLS 模式，并确保在整个迁移过程中不干扰在线流量的正常通信。
|
||||
本任务阐述如何将 Istio 服务的请求从明文模式平滑过渡至双向
|
||||
TLS 模式，并确保在整个迁移过程中不干扰在线流量的正常通信。
|
||||
|
||||
在调用其他工作负载时，Istio 会自动配置工作负载 sidecar 以使用[双向 TLS](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-tls)。
|
||||
在调用其他工作负载时，Istio 会自动配置工作负载 sidecar
|
||||
以使用[双向 TLS](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-tls)。
|
||||
默认情况下，Istio 使用 `PERMISSIVE` 模式配置目标工作负载。
|
||||
当启用 `PERMISSIVE` 模式时，服务可以接受明文和双向 TLS 流量。
|
||||
为了只允许双向 TLS 流量，需要将配置更改为 `STRICT` 模式。
|
||||
|
||||
您可以使用
|
||||
[Grafana dashboard](/zh/docs/tasks/observability/metrics/using-istio-dashboard/) 检查哪些服务仍然向 `PERMISSIVE` 模式的服务发送明文请求，然后选择在这些服务迁移结束后，将其锁定为只接收双向 TLS 请求。
|
||||
[Grafana dashboard](/zh/docs/tasks/observability/metrics/using-istio-dashboard/)
|
||||
检查哪些服务仍然向 `PERMISSIVE` 模式的服务发送明文请求，
|
||||
然后选择在这些服务迁移结束后，将其锁定为只接收双向 TLS 请求。
|
||||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies)以及相关的[双向 TLS 认证](/zh/docs/concepts/security/#mutual-tls-authentication)概念。
|
||||
|
||||
* 阅读[认证策略任务](/zh/docs/tasks/security/authentication/authn-policy)，了解如何配置认证策略。
|
||||
* 阅读[认证策略任务](/zh/docs/tasks/security/authentication/authn-policy)，
|
||||
了解如何配置认证策略。
|
||||
|
||||
* 有一个安装了 Istio 的 Kubernetes 集群，但没有启用全局双向 TLS（例如，使用[安装步骤](/zh/docs/setup/getting-started)中描述的 `default` 配置文件）。
|
||||
* 有一个安装了 Istio 的 Kubernetes 集群，但没有启用全局双向
|
||||
TLS（例如，使用[安装步骤](/zh/docs/setup/getting-started)中描述的 `default` 配置文件）。
|
||||
|
||||
在此任务中，您可以通过创建示例工作负载并修改策略以在工作负载之间强制执行 STRICT 双向 TLS 来尝试迁移过程。
|
||||
在此任务中，您可以通过创建示例工作负载并修改策略以在工作负载之间强制执行
|
||||
STRICT 双向 TLS 来尝试迁移过程。
|
||||
|
||||
## 设置集群{#set-up-the-cluster}
|
||||
|
||||
* 创建两个命名空间：`foo` 和 `bar`，并在这两个命名空间上部署 [httpbin]({{< github_tree >}}/samples/httpbin)、[sleep]({{< github_tree >}}/samples/sleep) 和 Sidecar。
|
||||
* 创建两个命名空间：`foo` 和 `bar`，并在这两个命名空间上部署
|
||||
[httpbin]({{< github_tree >}}/samples/httpbin)、
|
||||
[sleep]({{< github_tree >}}/samples/sleep) 和 Sidecar。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create ns foo
|
||||
|
|
@ -42,14 +51,16 @@ test: yes
|
|||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
|
||||
{{< /text >}}
|
||||
|
||||
* 创建另一个命名空间 `legacy`，并在没有 Sidecar 的情况下部署 [sleep]({{< github_tree >}}/samples/sleep)：
|
||||
* 创建另一个命名空间 `legacy`，并在没有 Sidecar 的情况下部署
|
||||
[sleep]({{< github_tree >}}/samples/sleep)：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create ns legacy
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
|
||||
{{< /text >}}
|
||||
|
||||
* （使用 curl 命令）从每个 Sleep Pod （命名空间为 `foo`、`bar` 或 `legacy`）分别向 `httpbin.foo` 发送 http 请求。所有请求都应成功响应，返回 HTTP code 200。
|
||||
* （使用 curl 命令）从每个 Sleep Pod（命名空间为 `foo`、`bar` 或 `legacy`）分别向
|
||||
`httpbin.foo` 发送 http 请求。所有请求都应成功响应，返回 HTTP code 200。
|
||||
|
||||
{{< text bash >}}
|
||||
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
|
||||
|
|
@ -63,7 +74,8 @@ test: yes
|
|||
|
||||
{{< tip >}}
|
||||
|
||||
如果任何 curl 命令失败，请确保可能干扰 httpbin 服务请求的现有身份验证策略或目标规则。
|
||||
如果任何 curl 命令失败，请确保可能干扰 httpbin
|
||||
服务请求的现有身份验证策略或目标规则。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get peerauthentication --all-namespaces
|
||||
|
|
@ -79,7 +91,8 @@ test: yes
|
|||
|
||||
## 通过命名空间锁定到双向 TLS{#lock-down-to-mutual-tls-by-namespace}
|
||||
|
||||
当所有客户端服务都成功迁移至 Istio 之后，注入 Envoy sidecar，便可以锁定 `httpbin.foo` 只接收双向 TLS 请求。
|
||||
当所有客户端服务都成功迁移至 Istio 之后，注入 Envoy sidecar，
|
||||
便可以锁定 `httpbin.foo` 只接收双向 TLS 请求。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -n foo -f - <<EOF
|
||||
|
|
@ -106,7 +119,8 @@ command terminated with exit code 56
|
|||
sleep.legacy to httpbin.bar: 200
|
||||
{{< /text >}}
|
||||
|
||||
如果您安装 Istio 时带有参数 `values.global.proxy.privileged=true`，那么您可以使用 `tcpdump` 来验证流量是否被加密。
|
||||
如果您安装 Istio 时带有参数 `values.global.proxy.privileged=true`，
|
||||
那么您可以使用 `tcpdump` 来验证流量是否被加密。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec -nfoo "$(kubectl get pod -nfoo -lapp=httpbin -ojsonpath={.items..metadata.name})" -c istio-proxy -- sudo tcpdump dst port 80 -A
|
||||
|
|
@ -114,7 +128,8 @@ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
|
|||
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
||||
{{< /text >}}
|
||||
|
||||
当分别从 `sleep.legacy` 和 `sleep.foo` 发送请求时，您将在输出中看到纯文本和加密文本。
|
||||
当分别从 `sleep.legacy` 和 `sleep.foo` 发送请求时，
|
||||
您将在输出中看到纯文本和加密文本。
|
||||
|
||||
若无法将所有服务迁移至 Istio （注入 Envoy sidecar），则必须开启 `PERMISSIVE` 模式。
|
||||
然而，开启 `PERMISSIVE` 模式时，系统默认不对明文请求进行认证或授权检查。
|
||||
|
|
@ -134,7 +149,8 @@ spec:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
现在，`foo` 和 `bar` 命名空间都强制执行仅双向 TLS 流量，因此您应该会看到来自 `sleep.legacy` 的请求访问两个命名空间的服务都失败了。
|
||||
现在，`foo` 和 `bar` 命名空间都强制执行仅双向 TLS 流量，
|
||||
因此您应该会看到来自 `sleep.legacy` 的请求访问两个命名空间的服务都失败了。
|
||||
|
||||
{{< text bash >}}
|
||||
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
|
||||
|
|
|
|||
|
|
@ -7,7 +7,8 @@ owner: istio/wg-security-maintainers
|
|||
test: yes
|
||||
---
|
||||
|
||||
此任务介绍如何设置 `DENY` 动作中的 Istio 授权策略，以明确拒绝 Istio 网格中的流量。这与 `ALLOW` 动作不同，因为 `DENY` 动作具有更高的优先级，不会被任何 `ALLOW` 动作绕过。
|
||||
此任务介绍如何设置 `DENY` 动作中的 Istio 授权策略，以明确拒绝 Istio 网格中的流量。
|
||||
这与 `ALLOW` 动作不同，因为 `DENY` 动作具有更高的优先级，不会被任何 `ALLOW` 动作绕过。
|
||||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
|
|
@ -19,7 +20,8 @@ test: yes
|
|||
|
||||
* 部署工作负载：
|
||||
|
||||
该任务使用 `httpbin` 和 `sleep` 这两个工作负载，部署在一个命名空间 foo。这两个工作负载在每个工作负载前都有一个 Envoy 代理。使用以下命令部署示例命名空间和工作负载：
|
||||
该任务使用 `httpbin` 和 `sleep` 这两个工作负载，部署在一个命名空间 foo。
|
||||
这两个工作负载在每个工作负载前都有一个 Envoy 代理。使用以下命令部署示例命名空间和工作负载：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create ns foo
|
||||
|
|
@ -35,12 +37,15 @@ test: yes
|
|||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
如果您在执行此任务时，没有看见到预期的输出，请您在几秒后重试。缓存和传播成本可能会导致一些延迟。
|
||||
如果您在执行此任务时，没有看见到预期的输出，请您在几秒后重试。
|
||||
缓存和传播成本可能会导致一些延迟。
|
||||
{{< /warning >}}
|
||||
|
||||
## 明确拒绝请求{#explicitly-deny-a-request}
|
||||
|
||||
1. 以下命令为 `foo` 命名空间中的 `httpbin` 工作负载创建 `deny-method-get` 授权策略。该授权将 `action` 设置为 `DENY`，以拒绝满足 `rules` 部分设置的条件的请求。该类型策略被称为“拒绝策略”。在这种情况下，如果请求方式是 `GET`，策略会拒绝请求。
|
||||
1. 以下命令为 `foo` 命名空间中的 `httpbin` 工作负载创建 `deny-method-get` 授权策略。
|
||||
该授权将 `action` 设置为 `DENY`，以拒绝满足 `rules` 部分设置的条件的请求。
|
||||
该类型策略被称为“拒绝策略”。在这种情况下，如果请求方式是 `GET`，策略会拒绝请求。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -75,7 +80,9 @@ test: yes
|
|||
200
|
||||
{{< /text >}}
|
||||
|
||||
1. 更新 `deny-method-get` 授权策略，只有当 HTTP 头中 `x-token` 值不是 `admin` 时才会拒绝 `GET` 请求。以下的策略示例将 `notValues` 字段的值设置为 `["admin"]`，以拒绝 HTTP 头中 `x-token` 值为非 `admin` 的请求：
|
||||
1. 更新 `deny-method-get` 授权策略，只有当 HTTP 头中 `x-token`
|
||||
值不是 `admin` 时才会拒绝 `GET` 请求。以下的策略示例将 `notValues`
|
||||
字段的值设置为 `["admin"]`，以拒绝 HTTP 头中 `x-token` 值为非 `admin` 的请求：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -113,7 +120,8 @@ test: yes
|
|||
403
|
||||
{{< /text >}}
|
||||
|
||||
1. 以下命令创建 `allow-path-ip` 授权策略，允许以 `/ip` 路径向 `httpbin` 工作负载发出请求。该授权策略设置 `action` 字段为 `ALLOW`。该类型的策略被称为“允许策略”。
|
||||
1. 以下命令创建 `allow-path-ip` 授权策略，允许以 `/ip` 路径向 `httpbin`
|
||||
工作负载发出请求。该授权策略设置 `action` 字段为 `ALLOW`。该类型的策略被称为“允许策略”。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
|
|||
Loading…
Reference in New Issue