mirror of https://github.com/istio/istio.io.git
[zh] improve webhook security-policy-examples architecture (#13172)
Signed-off-by: xin.li <xin.li@daocloud.io>
This commit is contained in:
my-git9
GitHub
parent
3dc1d16a1f
commit
7fa49ea88f
|
|
@ -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)）。
|
||||
|
|
|
|||
|
|
@ -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` 对代理容器进行临时调试的能力。
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 通信。
|
||||
|
|
|
|||
Loading…
Reference in New Issue