diff --git a/content/zh/docs/ops/configuration/mesh/webhook/index.md b/content/zh/docs/ops/configuration/mesh/webhook/index.md index fc32bf5723..e9a1c65fcd 100644 --- a/content/zh/docs/ops/configuration/mesh/webhook/index.md +++ b/content/zh/docs/ops/configuration/mesh/webhook/index.md @@ -12,18 +12,28 @@ test: no 来自 [Kubernetes 准入控制机制](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)： {{< tip >}} -准入 Webhook 是 HTTP 方式的回调，接收准入请求并对其进行相关操作。可定义两种类型的准入 Webhook，Validating 准入 Webhook 和 Mutating 准入 Webhook。使用 Validating Webhook，可以通过自定义的准入策略来拒绝请求；使用 Mutating Webhook，可以通过自定义默认值来修改请求。 +准入 Webhook 是 HTTP 方式的回调，接收准入请求并对其进行相关操作。 +可定义两种类型的准入 Webhook，Validating 准入 Webhook 和 Mutating +准入 Webhook。使用 Validating Webhook，可以通过自定义的准入策略来拒绝请求； +使用 Mutating Webhook，可以通过自定义默认值来修改请求。 {{< /tip >}} -Istio 使用 `ValidatingAdmissionWebhooks` 验证 Istio 配置，使用 `MutatingAdmissionWebhooks` 自动将 Sidecar 代理注入至用户 Pod。 +Istio 使用 `ValidatingAdmissionWebhooks` 验证 Istio 配置，使用 +`MutatingAdmissionWebhooks` 自动将 Sidecar 代理注入至用户 Pod。 -Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识。查阅 Kubernetes API 的相关资料，请参考 [Mutating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 和 [Validating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io)。 +Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识。 +查阅 Kubernetes API 的相关资料，请参 +[Mutating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) +和 [Validating Webhook Configuration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io)。 -## 验证动态准入 Webhook 前置条件 +## 验证动态准入 Webhook 前置条件 {#verify-dynamic-admission-webhook-prerequisites} -请参阅[平台设置说明](/zh/docs/setup/platform-setup/)了解 Kubernetes 提供的详细的设置说明。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，您可以通过以下步骤进行检查。 +请参阅[平台设置说明](/zh/docs/setup/platform-setup/)了解 Kubernetes +提供的详细的设置说明。如果集群配置错误，Webhook 将无法正常工作。集群配置后， +当动态 Webhook 和相关特性不能正常工作时，您可以通过以下步骤进行检查。 -1. 验证当前使用正确的 [`kubectl`](https://kubernetes.io/zh-cn/docs/tasks/tools/#kubectl) 和 Kubernetes 服务 [支持的版本](/zh/docs/releases/supported-releases#support-status-of-istio-releases)({{< supported_kubernetes_versions >}})： +1. 验证当前使用正确的 [`kubectl`](https://kubernetes.io/zh-cn/docs/tasks/tools/#kubectl) + 和 Kubernetes 服务[支持的版本](/zh/docs/releases/supported-releases#support-status-of-istio-releases)({{< supported_kubernetes_versions >}})： {{< text bash >}} $ kubectl version --short @@ -39,6 +49,11 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识 admissionregistration.k8s.io/v1beta1 {{< /text >}} -1. 验证 `kube-apiserver --enable-admission-plugins` 配置中插件 `MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook` 是否被启用。通过检查[指定规范](/zh/docs/setup/platform-setup/)中的标志(`--enable-admission-plugins`)。 +1. 验证 `kube-apiserver --enable-admission-plugins` 配置中插件 + `MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook` + 是否被启用。通过检查[指定规范](/zh/docs/setup/platform-setup/)中的标志（`--enable-admission-plugins`）。 -1. 验证 Kubernetes API Server 与 Webhook 所在 Pod 的网络连通是否正常。例如错误配置 `http_proxy` 可能干扰 API Server 正常运行（详细信息请参阅 [PR](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) 和 [Issue](https://github.com/kubernetes/kubeadm/issues/666))。 +1. 验证 Kubernetes API Server 与 Webhook 所在 Pod 的网络连通是否正常。 + 例如错误配置 `http_proxy` 可能干扰 API Server 正常运行（详细信息请参阅 + [PR](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) + 和 [Issue](https://github.com/kubernetes/kubeadm/issues/666)）。 diff --git a/content/zh/docs/ops/configuration/security/harden-docker-images/index.md b/content/zh/docs/ops/configuration/security/harden-docker-images/index.md index 6308ffa98d..5be2ee09ab 100644 --- a/content/zh/docs/ops/configuration/security/harden-docker-images/index.md +++ b/content/zh/docs/ops/configuration/security/harden-docker-images/index.md @@ -22,7 +22,7 @@ Istio 的[默认镜像](https://hub.docker.com/r/istio/base)基于 `ubuntu` 添 请参考官方 Distroless README 的[为何选择 Distroless 镜像？](https://github.com/GoogleContainerTools/distroless#why-should-i-use-distroless-images) 章节。 -## 安装 Distroless 镜像{#install-distroless-images} +## 安装 Distroless 镜像 {#install-distroless-images} 按照[安装步骤](/zh/docs/setup/install/istioctl/)配置 Istio。 添加 `variant` 选项以使用 **Distroless 镜像** 。 @@ -32,10 +32,10 @@ $ istioctl install --set values.global.variant=distroless {{< /text >}} 如果您只对将 Distroless 镜像用于注入的代理镜像感兴趣， -您还可以使用 [Proxy Config](/zh/docs/reference/config/networking/proxy-config/#ProxyImage) 中的 `proxyImage` 字段。 -请注意，上面的 `variant` 标志会自动为您设置该字段。 +您还可以使用 [Proxy Config](/zh/docs/reference/config/networking/proxy-config/#ProxyImage) +中的 `proxyImage` 字段。请注意，上面的 `variant` 标志会自动为您设置该字段。 -## 调试{#debugging} +## 调试 {#debugging} Distroless 镜像缺少所有调试工具（包括 Shell！）。 虽然对安全性有好处，但这限制了使用 `kubectl exec` 对代理容器进行临时调试的能力。 diff --git a/content/zh/docs/ops/configuration/security/security-policy-examples/index.md b/content/zh/docs/ops/configuration/security/security-policy-examples/index.md index 3662048cc7..6d74016f8a 100644 --- a/content/zh/docs/ops/configuration/security/security-policy-examples/index.md +++ b/content/zh/docs/ops/configuration/security/security-policy-examples/index.md @@ -6,16 +6,17 @@ owner: istio/wg-security-maintainers test: yes --- -## 背景{#background} +## 背景 {#background} 本页展示了使用 Istio 安全策略的通用模式。 您可能发现这些模式在部署时很有用，还可以将其用作策略示例的快速参考。 此处展示的这些策略只是示例，在应用前需要进行修改才能适配您的实际环境。 -另请参阅[身份验证](/zh/docs/tasks/security/authentication/authn-policy)和[鉴权](/zh/docs/tasks/security/authorization)任务，了解如何使用安全策略的实践教程。 +另请参阅[身份验证](/zh/docs/tasks/security/authentication/authn-policy)和[鉴权](/zh/docs/tasks/security/authorization)任务， +了解如何使用安全策略的实践教程。 -### 每个主机需要不同的 JWT 签名者{#require-different-jwt-issuer-per-host} +### 每个主机需要不同的 JWT 签名者 {#require-different-jwt-issuer-per-host} JWT 校验通常用于 Ingress Gateway，您可能需要为不同的主机使用不同的 JWT 签名者。 除了[请求身份验证](/zh/docs/tasks/security/authentication/authn-policy/#end-user-authentication)策略， @@ -52,9 +53,10 @@ spec: hosts: [".another.org", "*.another.org"] {{< /text >}} -### 命名空间隔离{#namespace-isolation} +### 命名空间隔离 {#namespace-isolation} -以下两个策略对命名空间 `foo` 启用了 `STRICT` mTLS，允许来自相同命名空间的流量。 +以下两个策略对命名空间 `foo` 启用了 `STRICT` mTLS， +允许来自相同命名空间的流量。 {{< text yaml >}} apiVersion: security.istio.io/v1beta1 @@ -81,7 +83,8 @@ spec: ### 将 Ingress 排除在外的命名空间隔离 {#namespace-isolation-with-ingress-exception} -以下两个策略对命名空间 `foo` 启用了 Strict mTLS，允许来自相同命名空间和 Ingress Gateway 的流量。 +以下两个策略对命名空间 `foo` 启用了 Strict mTLS，允许来自相同命名空间和 +Ingress Gateway 的流量。 {{< text yaml >}} apiVersion: security.istio.io/v1beta1 @@ -131,14 +134,15 @@ spec: notPrincipals: ["*"] {{< /text >}} -### 使用 `DENY` 策略时要求强制的鉴权检查{#require-mandatory-authorization-check-with-deny-policy} +### 使用 `DENY` 策略时要求强制的鉴权检查 {#require-mandatory-authorization-check-with-deny-policy} -如果想要强制鉴权检查必须被满足且不能被另一个更宽松的 `ALLOW` 策略绕过，您可以使用 `DENY` 策略。 -这种做法很有效，因为 `DENY` 策略优先于 `ALLOW` 策略，并且可以在 `ALLOW` 策略之前就拒绝请求。 +如果想要强制鉴权检查必须被满足且不能被另一个更宽松的 `ALLOW` 策略绕过， +您可以使用 `DENY` 策略。这种做法很有效，因为 `DENY` 策略优先于 `ALLOW` +策略，并且可以在 `ALLOW` 策略之前就拒绝请求。 -除了[请求身份验证](/zh/docs/tasks/security/authentication/authn-policy/#end-user-authentication)策略之外，还可以使用以下策略强制执行 JWT 校验。 -如果请求主体为空，此策略将拒绝请求。如果 JWT 校验失败，请求主体将为空。 -换言之，如果请求主体非空，此策略将允许这些请求。 +除了[请求身份验证](/zh/docs/tasks/security/authentication/authn-policy/#end-user-authentication)策略之外， +还可以使用以下策略强制执行 JWT 校验。如果请求主体为空，此策略将拒绝请求。 +如果 JWT 校验失败，请求主体将为空。换言之，如果请求主体非空，此策略将允许这些请求。 `"*"` 意味着非空匹配，与 `notRequestPrincipals` 一起使用时意味着匹配空请求主体。 {{< text yaml >}} @@ -158,9 +162,12 @@ spec: notRequestPrincipals: ["*"] {{< /text >}} -类似地，使用以下策略需要强制地命名空间隔离，也允许来自 Ingress Gateway 的请求。 -如果命名空间不是 `foo` 且主体不是 `cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account`， -此策略将拒绝请求。换言之，只有命名空间是 `foo` 或主体是 `cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account`，此策略才允许请求。 +类似地，使用以下策略需要强制地命名空间隔离，也允许来自 Ingress Gateway +的请求。如果命名空间不是 `foo` 且主体不是 +`cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account`， +此策略将拒绝请求。换言之，只有命名空间是 `foo` 或主体是 +`cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account`， +此策略才允许请求。 {{< text yaml >}} apiVersion: security.istio.io/v1beta1 diff --git a/content/zh/docs/ops/deployment/architecture/index.md b/content/zh/docs/ops/deployment/architecture/index.md index d4b5422e21..a003662e5b 100644 --- a/content/zh/docs/ops/deployment/architecture/index.md +++ b/content/zh/docs/ops/deployment/architecture/index.md @@ -11,7 +11,9 @@ test: n/a Istio 服务网格从逻辑上分为**数据平面**和**控制平面**。 -- **数据平面** 由一组智能代理（[Envoy](https://www.envoyproxy.io/)）组成，被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。 +- **数据平面** 由一组智能代理（[Envoy](https://www.envoyproxy.io/)）组成， + 被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。 + 它们还收集和报告所有网格流量的遥测数据。 - **控制平面** 管理并配置代理来进行流量路由。 @@ -23,13 +25,15 @@ Istio 服务网格从逻辑上分为**数据平面**和**控制平面**。 caption="Istio Architecture" >}} -## 组件{#components} +## 组件 {#components} 以下各节概述了 Istio 的每个核心组件。 -### Envoy{#envoy} +### Envoy {#envoy} -Istio 使用 [Envoy](https://www.envoyproxy.io/) 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。 +Istio 使用 [Envoy](https://www.envoyproxy.io/) 代理的扩展版本。Envoy +是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy +代理是唯一与数据平面流量交互的 Istio 组件。 Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如： @@ -43,7 +47,8 @@ Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy - 故障注入 - 丰富的指标 -这种 Sidecar 部署允许 Istio 可以执行策略决策，并提取丰富的遥测数据，接着将这些数据发送到监视系统以提供有关整个网格行为的信息。 +这种 Sidecar 部署允许 Istio 可以执行策略决策，并提取丰富的遥测数据， +接着将这些数据发送到监视系统以提供有关整个网格行为的信息。 Sidecar 代理模型还允许您向现有的部署添加 Istio 功能，而不需要重新设计架构或重写代码。 @@ -54,16 +59,23 @@ Sidecar 代理模型还允许您向现有的部署添加 Istio 功能，而不 - 安全性和身份认证特性：执行安全性策略，并强制实行通过配置 API 定义的访问控制和速率限制。 - 基于 WebAssembly 的可插拔扩展模型，允许通过自定义策略执行和生成网格流量的遥测。 -### Istiod +### Istiod {#istiod} Istiod 提供服务发现、配置和证书管理。 -Istiod 将控制流量行为的高级路由规则转换为 Envoy 特定的配置，并在运行时将其传播给 Sidecar。Pilot 提取了特定平台的服务发现机制，并将其综合为一种标准格式，任何符合 [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) 的 Sidecar 都可以使用。 +Istiod 将控制流量行为的高级路由规则转换为 Envoy 特定的配置， +并在运行时将其传播给 Sidecar。Pilot 提取了特定平台的服务发现机制， +并将其综合为一种标准格式，任何符合 [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) +的 Sidecar 都可以使用。 Istio 可以支持发现多种环境，如 Kubernetes 或 VM。 -您可以使用 Istio [流量管理 API](/zh/docs/concepts/traffic-management/#introducing-istio-traffic-management) 让 Istiod 重新构造 Envoy 的配置，以便对服务网格中的流量进行更精细的控制。 +您可以使用 Istio [流量管理 API](/zh/docs/concepts/traffic-management/#introducing-istio-traffic-management) +让 Istiod 重新构造 Envoy 的配置，以便对服务网格中的流量进行更精细的控制。 -Istiod [安全](/zh/docs/concepts/security/)通过内置的身份和凭证管理，实现了强大的服务对服务和终端用户认证。您可以使用 Istio 来升级服务网格中未加密的流量。使用 Istio，运营商可以基于服务身份而不是相对不稳定的第 3 层或第 4 层网络标识符来执行策略。此外，您可以使用 [Istio 的授权功能](/zh/docs/concepts/security/#authorization)控制谁可以访问您的服务。 +Istiod [安全](/zh/docs/concepts/security/)通过内置的身份和凭证管理， +实现了强大的服务对服务和终端用户认证。您可以使用 Istio 来升级服务网格中未加密的流量。 +使用 Istio，运营商可以基于服务身份而不是相对不稳定的第 3 层或第 4 层网络标识符来执行策略。 +此外，您可以使用 [Istio 的授权功能](/zh/docs/concepts/security/#authorization)控制谁可以访问您的服务。 Istiod 充当证书授权（CA），并生成证书以允许在数据平面中进行安全的 mTLS 通信。