mirror of https://github.com/istio/istio.io.git
[zh] sync /ops/best-practices/security/ (#13663)
* [zh] sync /ops/best-practices/security/ * apply suggestions from wilsonwu
This commit is contained in:
Michael
GitHub
parent
44b966134a
commit
71f54f49e5
|
|
@ -7,20 +7,20 @@ owner: istio/wg-security-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密，认证，
|
||||
Istio 安全功能提供强大的身份、强大的策略、透明的 TLS 加密、认证、
|
||||
授权和审计（AAA）工具来保护您的服务和数据。但是，为了更好地使用这些安全特性，
|
||||
必须按照最佳实践操作。这里建议您在阅读下文前回顾[安全概述](/zh/docs/concepts/security/)。
|
||||
必须按照最佳实践操作。这里建议您先回顾[安全概述](/zh/docs/concepts/security/)再阅读下文。
|
||||
|
||||
## 双向 TLS {#mutual-tls}
|
||||
|
||||
Istio 会在尽可能[自动](/zh/docs/ops/configuration/traffic-management/tls-configuration/#auto-mtls)
|
||||
地对流量进行[双向 TLS](/zh/docs/concepts/security/#mutual-tls-authentication) 加密。但是，
|
||||
默认情况下代理会工作在[宽容模式](/zh/docs/concepts/security/#permissive-mode)下，
|
||||
这意味着代理会允许双向 TLS 认证的流量以及纯文本流量。
|
||||
默认情况下代理会工作在[宽容（PERMISSIVE）模式](/zh/docs/concepts/security/#permissive-mode)下，
|
||||
这意味着代理会允许双向 TLS 认证的流量以及明文流量。
|
||||
|
||||
尽管对于渐进式配置或允许流量来自没有 Istio 代理的客户端来说，这个模式是必需的。但这个模式也削弱了安全性，
|
||||
因此，为了强制在流量进行双向 TLS 认证，
|
||||
应建议尽早[迁移到 strict 模式](/zh/docs/tasks/security/authentication/mtls-migration/)。
|
||||
应建议尽早[迁移到严格（STRICT）模式](/zh/docs/tasks/security/authentication/mtls-migration/)。
|
||||
|
||||
双向 TLS 本身不总是能够保证安全流量，因为它只提供了认证，而不是授权。
|
||||
这意味着任何拥有有效证书的人都可以访问负载。
|
||||
|
|
@ -53,12 +53,12 @@ default-deny 授权策略意味着您的系统在默认情况下拒绝所有请
|
|||
尽可能使用 `ALLOW-with-positive-matching` 或 `DENY-with-negative-matching` 授权策略模式。
|
||||
这些授权策略模式更安全，因为在策略不匹配的情况下，最坏的结果是收到一个意外拒绝403，而不是绕过授权策略。
|
||||
|
||||
`ALLOW-with-positive-matching` 授权策略模式是仅对 **positive** 匹配字段（例如
|
||||
`paths`、`values`）使用 `ALLOW` 动作，而不要使用任何 **negative** 匹配字段（例如
|
||||
`notPaths`、`notValues`）。
|
||||
`ALLOW-with-positive-matching` 授权策略模式是仅对 **positive** 匹配字段
|
||||
（例如 `paths`、`values`）使用 `ALLOW` 动作，而不要使用任何 **negative** 匹配字段
|
||||
（例如 `notPaths`、`notValues`）。
|
||||
|
||||
`DENY-with-negative-matching` 授权策略模式是仅对 **negative** 匹配字段（例如
|
||||
`notPaths`、`notValues`）使用 `DENY` 动作 ，而不要使用任何 **positive**
|
||||
`DENY-with-negative-matching` 授权策略模式是仅对 **negative** 匹配字段
|
||||
（例如 `notPaths`、`notValues`）使用 `DENY` 动作 ，而不要使用任何 **positive**
|
||||
匹配字段（例如 `paths`、`values`）。
|
||||
|
||||
例如，下面的授权策略使用 `ALLOW-with-positive-matching` 模式，允许对路径 `/public` 的请求：
|
||||
|
|
@ -130,7 +130,7 @@ Istio 授权策略实现了对各种基本规范化选项的内置支持，以
|
|||
|
||||
### 配置路径规范化选项的指导原则 {#guideline-on-configuring-the-path-normalization-option}
|
||||
|
||||
#### 案例 1：您不需要规范化 {#case-1:-you-do-not-need-normalization-at-all}
|
||||
#### 案例 1：您不需要规范化 {#case-1-you-do-not-need-normalization-at-all}
|
||||
|
||||
在深入了解配置规范化的细节之前，您应该首先确定是否需要规范化。
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ Istio 授权策略实现了对各种基本规范化选项的内置支持，以
|
|||
如果您所有的授权策略都遵循[更安全的授权模式](/zh/docs/ops/best-practices/security/#safer-authorization-policy-patterns)，
|
||||
您可能不需要规范化, 在最坏的情况下，这会导致意外拒绝而不是策略绕过。
|
||||
|
||||
#### 案例 2：您需要规范化，但不确定使用哪个规范化选项 {#case-2:-you-need-normalization-but-not-sure-which-normalization-option-to-use}
|
||||
#### 案例 2：您需要规范化，但不确定使用哪个规范化选项 {#case-2-you-need-normalization-but-not-sure-which-normalization-option-to-use}
|
||||
|
||||
如果您需要规范化，但不知道要使用哪个选项。最安全的选择是最严格的规范化选项，
|
||||
它在授权策略中提供了最高级别的规范化。
|
||||
|
|
@ -154,7 +154,7 @@ Istio 授权策略实现了对各种基本规范化选项的内置支持，以
|
|||
|
||||
参考[自定义系统的路径规范化](/zh/docs/ops/best-practices/security/#customize-your-system-onpath-normalization)以了解更多配置规范化选项的细节。
|
||||
|
||||
#### 案例 3：您需要一个不支持的规范化选项 {#case-3:-you-need-an-unsupported-normalization-option}
|
||||
#### 案例 3：您需要一个不支持的规范化选项 {#case-3-you-need-an-unsupported-normalization-option}
|
||||
|
||||
如果您需要 Istio 还不支持的特定规范化选项，
|
||||
请按照[不支持规范化的缓解措施](/zh/docs/ops/best-practices/security/#mitigation-for-unsupported-normalization)来获得自定义规范化支持或为
|
||||
|
|
@ -163,30 +163,31 @@ Istio 社区创建功能请求。
|
|||
### 在路径规范化上自定义系统 {#customize-your-system-on-path-normalization}
|
||||
|
||||
Istio 授权策略能够基于 HTTP 请求的 URL 路径实现。
|
||||
[路径规范化(即 URI 规范化)](https://en.wikipedia.org/wiki/URI_normalization)修改并标准化了入站请求的路径，
|
||||
[路径规范化（即 URI 规范化）](https://en.wikipedia.org/wiki/URI_normalization)修改并标准化了入站请求的路径，
|
||||
因此规范化后的路径可以按照标准进行处理。语法上来说，不同的路径在规范化之后可能是一致的。
|
||||
|
||||
在评估授权策略和路由请求之前， Istio 支持以下的请求路径规范化方案：
|
||||
在评估授权策略和路由请求之前，Istio 支持以下的请求路径规范化方案：
|
||||
|
||||
| 选项 | 描述 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| `NONE` | 没有规范化。Envoy 代理受到的一切都按照原样转发到后端负载。 | `../%2Fa../b` 将被授权策略评估并且发送到您的负载。 |
|
||||
| `BASE` | 这是目前 Istio 使用的**默认**安装选项。此选项将[规范化路径](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)应用于 Envoy 代理上。该规范符合 [RFC 3986](https://tools.ietf.org/html/rfc3986) 同时附加规范将反斜线转化为斜线。 | `/a/../b` 规范为 `/b`。 `\da` 规范为 `/da`。 |
|
||||
| `MERGE_SLASHES` | 在 **BASE** 规范化之后合并斜线。 | `/a//b` 规范为 `/a/b`。 |
|
||||
| `DECODE_AND_MERGE_SLASHES` | 当您默认允许所有流量时，这为最严格的设置。若您想要详尽地测试您的路由授权策略时，这是推荐选项。在 `MERGE_SLASHES` 之前，被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜线和反斜线字符 (`%2F`, `%2f`, `%5C` and `%5c`) 解码为 `/` 或 `\`。 | `/a%2fb` 规范为 `/a/b`。 |
|
||||
| `BASE` | 这是目前 Istio 使用的**默认**安装选项。此选项将[规范化路径](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)应用于 Envoy 代理上。该规范符合 [RFC 3986](https://tools.ietf.org/html/rfc3986) 同时附加规范将反斜杠转化为斜杠。 | `/a/../b` 规范为 `/b`。 `\da` 规范为 `/da`。 |
|
||||
| `MERGE_SLASHES` | 在 **BASE** 规范化之后合并斜杠。 | `/a//b` 规范为 `/a/b`。 |
|
||||
| `DECODE_AND_MERGE_SLASHES` | 当您默认允许所有流量时，这为最严格的设置。若您想要详尽地测试您的路由授权策略时，这是推荐选项。在 `MERGE_SLASHES` 之前，被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜杠和反斜杠字符（`%2F`、`%2f`、`%5C` 和 `%5c`）解码为 `/` 或 `\`。 | `/a%2fb` 规范为 `/a/b`。 |
|
||||
|
||||
{{< tip >}}
|
||||
这项配置声明在 [mesh config](/zh/docs/reference/config/istio.mesh.v1alpha1/)
|
||||
的 [`pathNormalization`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization)
|
||||
这项配置声明在[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/)的
|
||||
[`pathNormalization`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization)
|
||||
字段。
|
||||
{{< /tip >}}
|
||||
|
||||
着重强调，规范化算法按照以下顺序执行：
|
||||
1. 百分位解码 `%2F`, `%2f`, `%5C` 和 `%5c`。
|
||||
|
||||
1. 百分位解码 `%2F`、`%2f`、`%5C` 和 `%5c`。
|
||||
1. [RFC 3986](https://tools.ietf.org/html/rfc3986) 以及其他由
|
||||
Envoy [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)
|
||||
选项实现的规范。
|
||||
1. 合并斜线。
|
||||
1. 合并斜杠。
|
||||
|
||||
{{< warning >}}
|
||||
尽管这些规范化选项是 HTTP 标准和业界推荐设置。应用本身也可能选择使用自定义的 URL。
|
||||
|
|
@ -205,10 +206,10 @@ Istio 授权策略能够基于 HTTP 请求的 URL 路径实现。
|
|||
|
||||
| 您的应用... | 选择... |
|
||||
| --- | --- |
|
||||
| 依赖代理完成规范化。 | `BASE`, `MERGE_SLASHES` 或 `DECODE_AND_MERGE_SLASHES` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径并且不合并斜线 | `BASE` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径，合并斜线但是不解码被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜线 | `MERGE_SLASHES` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径，合并斜线并解码被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜线 | `DECODE_AND_MERGE_SLASHES` |
|
||||
| 依赖代理完成规范化。 | `BASE`、`MERGE_SLASHES` 或 `DECODE_AND_MERGE_SLASHES` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径并且不合并斜杠 | `BASE` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径，合并斜杠但是不解码被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜杠 | `MERGE_SLASHES` |
|
||||
| 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986) 规范化请求路径，合并斜杠并解码被[百分位编码](https://tools.ietf.org/html/rfc3986#section-2.1)的斜杠 | `DECODE_AND_MERGE_SLASHES` |
|
||||
| 采用与 [RFC 3986](https://tools.ietf.org/html/rfc3986) 不兼容的方式处理请求路径。 | `NONE` |
|
||||
|
||||
### 如何配置 {#how-to-configure}
|
||||
|
|
@ -219,7 +220,7 @@ Istio 授权策略能够基于 HTTP 请求的 URL 路径实现。
|
|||
$ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES
|
||||
{{< /text >}}
|
||||
|
||||
或者修改您的 operator 来复写文件
|
||||
或者修改您的 Operator 来复写文件：
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF > iop.yaml
|
||||
|
|
@ -233,7 +234,8 @@ EOF
|
|||
$ istioctl install -f iop.yaml
|
||||
{{< /text >}}
|
||||
|
||||
或者，如果您想直接修改网格配置，您可以将 [`pathNormalization`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization)
|
||||
或者，如果您想直接修改网格配置，您可以将
|
||||
[`pathNormalization`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ProxyPathNormalization)
|
||||
加入[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/)中，即修改 `istio-system`
|
||||
命名空间中的 `istio-<REVISION_ID>` configmap。例如，如果您使用 `DECODE_AND_MERGE_SLASHES`
|
||||
选项，您需要按照如下修改网格配置：
|
||||
|
|
@ -257,12 +259,13 @@ apiVersion: v1
|
|||
#### 自定义规范化逻辑 {#custom-normalization-logic}
|
||||
|
||||
您可以使用 WASM 或 Lua 过滤器应用自定义规范化逻辑。建议使用 WASM 过滤器，因为 Istio 官方支持并使用它。
|
||||
您可以使用 Lua 过滤器进行快速概念验证 DEMO，但我们这样做不建议在生产环境中使用 Lua 过滤器，因为 Istio 不支持它。
|
||||
您可以使用 Lua 过滤器进行快速概念验证 DEMO，但我们这样做不建议在生产环境中使用 Lua 过滤器，因为 Istio 不支持 Lua 过滤器。
|
||||
|
||||
#### 大小写规范化 {#case-normalization}
|
||||
|
||||
在一些环境下，需要不区分授权策略中路径的大小写。
|
||||
例如，将 `https://myurl/get` 和 `https://myurl/GeT` 视为等效。
|
||||
|
||||
在这些情况下，可以使用如下的 `EnvoyFilter`。
|
||||
此设置将同时改变策略对比所用的以及传递给应用的路径。
|
||||
|
||||
|
|
@ -322,23 +325,23 @@ spec:
|
|||
{{< /text >}}
|
||||
|
||||
此外，`host` 和 `notHosts` 字段通常应该只用在进入网格的外部流量的网关上，而不是在网格内流量的 Sidecar
|
||||
上，这是因为服务器端的 Sidecar（执行授权策略的地方）在将请求重定向到应用程序时，不使用 `Host` 字段
|
||||
上，这是因为服务器端的 Sidecar（执行授权策略的地方）在将请求重定向到应用程序时，不使用 `Host` 字段。
|
||||
由于客户端可以使用明确的 IP 地址和任意的 `Host` 头而不是服务名称来访问应用程序，这使得 `host` 和
|
||||
`notHost` 在 Sidecar 上没有意义。
|
||||
|
||||
如果您真的需要基于 sidecar 上的 `Host` 标头执行访问控制，请遵循
|
||||
如果您真得需要基于 Sidecar 上的 `Host` 标头执行访问控制，请遵循
|
||||
[default-deny 授权策略模式](/zh/docs/ops/best-practices/security/#use-default-deny-patterns)，
|
||||
如果客户端使用任意的 `Host` 标头，它将拒绝该请求。
|
||||
|
||||
#### 专门的网络应用防火墙 (WAF) {#specialized-web-application-firewall}
|
||||
#### 专门的网络应用防火墙（WAF） {#specialized-web-application-firewall}
|
||||
|
||||
许多专门的 Web 应用程序防火墙 (WAF) 产品提供额外的规范化选项。它们可以部署在 Istio 入口网关的前端，
|
||||
许多专门的 Web 应用程序防火墙（WAF）产品提供额外的规范化选项。它们可以部署在 Istio 入口网关的前端，
|
||||
以规范化进入网格的请求。然后，授权策略将在规范化的请求上执行。请参考您的特定 WAF 产品以配置规范化选项。
|
||||
|
||||
#### 对 Istio 的功能请求 {#feature-request-to-istio}
|
||||
|
||||
如果您认为 Istio 应该正式支持某个特定的规范化，您可以按照
|
||||
[报告漏洞](/zh/docs/releases/security-vulnerabilities/#reporting-a-vulnerability)页面，
|
||||
如果您认为 Istio 应该正式支持某个特定的规范化，
|
||||
您可以按照[报告漏洞](/zh/docs/releases/security-vulnerabilities/#reporting-a-vulnerability)页面，
|
||||
向 Istio 产品安全工作组发送关于特定规范化的功能请求，以便进行初步评估。
|
||||
|
||||
在未与 Istio 产品安全工作组联系之前，请不要公开任何问题，因为该问题可能被视为需要私下修复的安全漏洞。
|
||||
|
|
@ -360,7 +363,8 @@ spec:
|
|||
|
||||
如果由服务器优先 TCP 协议发送的第一个字节包含任何需要通过适当授权保护的敏感数据，则不应使用授权策略。
|
||||
|
||||
如果第一个字节不包含任何敏感数据，您仍然可以在这种情况下使用授权策略，例如，第一个字节是用来与任何客户公开访问的数据协商连接的。
|
||||
如果第一个字节不包含任何敏感数据，您仍然可以在这种情况下使用授权策略，
|
||||
例如第一个字节是用来与任何客户公开访问的数据协商连接的。
|
||||
对于客户端在第一个字节之后发送的以下请求，授权策略将照常工作。
|
||||
|
||||
## 理解流量拦截的局限性 {#understand-traffic-capture-limitations}
|
||||
|
|
@ -371,22 +375,22 @@ Istio Sidecar 原理为拦截入站和出站流量并将它们转发到 Sidecar
|
|||
|
||||
* 转发只针对基于 TCP 的流量。任何 UDP 或 ICMP 包不会被拦截或更改。
|
||||
* 入站拦截在很多 [Sidecar 使用的端口](/zh/docs/ops/deployment/requirements/#ports-used-by-istio)以及端口
|
||||
22 不生效。此列表可以通过例如 `traffic.sidecar.istio.io/excludeInboundPorts` 的设置拓展。
|
||||
22 不生效。此列表可以通过 `traffic.sidecar.istio.io/excludeInboundPorts` 这类选项扩展。
|
||||
* 出站拦截可以通过类似 `traffic.sidecar.istio.io/excludeOutboundPorts` 的配置以及其他多种方式取消。
|
||||
|
||||
总的来说，一个应用和他的 Sidecar 代理之间的安全边界微乎其微。Sidecar 设置基于 Pod 粒度设置，
|
||||
并且二者运行在同一个网络/进程空间。因此，应用可能移除拦截规则，并且移除，修改，或替换 Sidecar
|
||||
代理。这允许一个 Pod 将出站流量有意地绕过它的 Sidecar 或者 有意允许入站流量绕过它的 Sidecar。
|
||||
总的来说，一个应用及其 Sidecar 代理之间的安全边界微乎其微。Sidecar 设置基于 Pod 粒度设置，
|
||||
并且二者运行在同一个网络/进程空间。因此，应用可能移除拦截规则，并且移除、修改或替换 Sidecar
|
||||
代理。这允许一个 Pod 将出站流量有意地绕过它的 Sidecar 或者有意允许入站流量绕过它的 Sidecar。
|
||||
|
||||
因此，仅依赖 Istio 来拦截全部流量是不安全的。取而代之，正确的安全边界是，
|
||||
一个客户端不应该能够绕过**另一个** Pod 的 Sidecar。
|
||||
因此，仅依赖 Istio 来拦截全部流量是不安全的。取而代之，
|
||||
正确的安全边界是一个客户端不应该能够绕过**另一个** Pod 的 Sidecar。
|
||||
|
||||
例如，如果在端口 `9080` 上运行 `reviews` 应用，便应认为所有从 `productpage`
|
||||
应用来的流量都应被 `review` Sidecar 代理拦截，在 Sidecar 上便可以进行 Istio 认证和授权策略配置。
|
||||
|
||||
### 基于 `NetworkPolicy` 的纵深防御 {#defense-in-depth-with-network-policy}
|
||||
|
||||
为了进一步确保流量安全， Istio 策略可以基于 Kubernetes
|
||||
为了进一步确保流量安全，Istio 策略可以基于 Kubernetes
|
||||
[网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/)。
|
||||
这将启动强大的[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))策略来进一步确保您的网格安全性。
|
||||
|
||||
|
|
@ -396,29 +400,29 @@ Pod 或者有安全弱点情况下，这可能限制或者阻止攻击者。
|
|||
根据实际执行情况，对网络策略的更改可能不会影响 Istio 代理中的现有连接。您可能需要在应用策略后重新启动
|
||||
Istio 代理，以便现有的连接将被关闭，新的连接将受到新策略的约束。
|
||||
|
||||
### 确保 egress 流量安全 {#securing-egress-traffic}
|
||||
### 确保 Egress 流量安全 {#securing-egress-traffic}
|
||||
|
||||
一个常见的误解是类似 [`outboundTrafficPolicy: REGISTRY_ONLY`](/zh/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services)
|
||||
的设置可以作为安全策略来阻止访问未声明服务。但是如上文所说这并不能作为一个很强的安全边界，
|
||||
而充其量应视为尽力而为。
|
||||
|
||||
尽管上面的设置可以防止意外的依赖，如果您想要确保 egress 的流量安全并强制所有的出站流量都通过代理，
|
||||
您应该使用 [Egress Gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/)。
|
||||
尽管上面的设置可以防止意外的依赖，如果您想要确保 Egress 的流量安全并强制所有的出站流量都通过代理，
|
||||
您应该使用 [Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/)。
|
||||
当结合[网络策略](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-kubernetes-network-policies)一起使用时，
|
||||
您可以强制所有出站流量，或者部分通过 egress 网关。这确保了即使客户端因意外或者被恶意绕过它的代理，请求将会被阻止。
|
||||
您可以强制所有出站流量，或者部分通过 Egress 网关。这确保了即使客户端因意外或者被恶意绕过它的代理，请求将会被阻止。
|
||||
|
||||
## 当使用 TLS 源时在目标规则上配置 TLS 验证 {#configure-TLS-verification-in-destination-rule-when-using-TLS-origination}
|
||||
|
||||
Istio 提供了从 Sidecar 代理或者网关上[发起 TLS](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)
|
||||
的能力。这使得从应用发出的纯文本 HTTP 流量可以透明地“升级”到 HTTPS。
|
||||
的能力。这使得从应用发出的明文 HTTP 流量可以透明地“升级”到 HTTPS。
|
||||
|
||||
当进行 `DestinationRule` 中的 `tls` 字段配置时，应格外注意 `caCertificates`、`subjectAltNames` 和 `sni` 字段。
|
||||
通过在 Istiod 上启用环境变量 `VERIFY_CERTIFICATE_AT_CLIENT=true` ，可以从系统证书存储的 CA 证书自动设置 `caCertificate` 。
|
||||
通过在 Istiod 上启用环境变量 `VERIFY_CERTIFICATE_AT_CLIENT=true`，可以从系统证书存储的 CA 证书自动设置 `caCertificate`。
|
||||
如果自动使用的操作系统 CA 证书只适用于特定的主机，环境变量 `VERIFY_CERTIFICATE_AT_CLIENT=false` 在 Istiod 上，
|
||||
`caCertificates` 可以被设置为 `system` 在所需的 `DestinationRule` 中。
|
||||
在 `DestinationRule` 中指定 `caCertificates` 将被优先考虑，操作系统 CA 证书将不被使用。
|
||||
默认情况下，出口流量在 TLS 握手期间不发送 SNI。
|
||||
SNI必须在 `DestinationRule` 中设置，以确保主机正确处理请求。
|
||||
SNI 必须在 `DestinationRule` 中设置，以确保主机正确处理请求。
|
||||
|
||||
{{< warning >}}
|
||||
为了验证服务器的证书，必须同时设置 `caCertificates` 和 `subjectAltNames`。
|
||||
|
|
@ -427,7 +431,7 @@ SNI必须在 `DestinationRule` 中设置，以确保主机正确处理请求。
|
|||
|
||||
如果 `VERIFY_CERTIFICATE_AT_CLIENT` 被设置，但 `subjectAltNames` 没有被设置，那么您就没有验证所有证书。
|
||||
|
||||
如果服务器未使用 CA 证书，则无论是否设置 `subjectAltNames` 都将不使用。
|
||||
如果服务器未使用 CA 证书，则无论是否设置 `subjectAltNames` 都将不会被使用。
|
||||
{{< /warning >}}
|
||||
|
||||
例如：
|
||||
|
|
@ -450,7 +454,7 @@ spec:
|
|||
|
||||
## 网关 {#gateways}
|
||||
|
||||
当运行一个 Istio [网关](/zh/docs/tasks/traffic-management/ingress/)时候，以下的资源都将参与：
|
||||
当运行一个 Istio [网关](/zh/docs/tasks/traffic-management/ingress/)时，将涉及以下的资源：
|
||||
|
||||
* `Gateway` 控制了网关的端口和 TLS 设置。
|
||||
* `VirtualService` 控制了路由逻辑。虚拟服务通过 `Gateway` 资源的 `gateways` 的字段直接被引用。
|
||||
|
|
@ -503,7 +507,7 @@ servers:
|
|||
### 显式阻止所有的敏感 http 主机被宽泛的 SNI 匹配 {#explicitly-disable-all-the-sensitive-http-host-under-relaxed-SNI-host-matching}
|
||||
|
||||
使用多个 `Gateway` 资源来在不同的主机上定义多个双向或者单向 TLS 是很合理的。
|
||||
例如，在 SNI 主机 `admin.example.com` 上使用双向 TLS， 在 SNI 主机 `*.example.com` 上使用单向 TLS。
|
||||
例如，在 SNI 主机 `admin.example.com` 上使用双向 TLS，在 SNI 主机 `*.example.com` 上使用单向 TLS。
|
||||
|
||||
{{< text yaml >}}
|
||||
kind: Gateway
|
||||
|
|
@ -540,9 +544,9 @@ spec:
|
|||
{{< /text >}}
|
||||
|
||||
如果以上设置是必要的，那么推荐您显式地将 http 主机 `admin.example.com` 从配置了 `*.example.com`
|
||||
的虚拟服务中剔除。因为现在 [envoy 代理不要求](https://github.com/envoyproxy/envoy/issues/6767)
|
||||
http 1 头部 `Host` 或者 http 2 伪头部 `:authority` 字段遵守 SNI 限制。 这意味着攻击者可以复用访客的
|
||||
SNI TLS 连接来访问管理员`虚拟服务`。而 http 回复代码 421 的设计目的便是 `Host` SNI 不匹配并且可以用于以上阻止目的。
|
||||
的虚拟服务中剔除。因为现在 [Envoy 代理不要求](https://github.com/envoyproxy/envoy/issues/6767)
|
||||
http 1 头部 `Host` 或者 http 2 伪头部 `:authority` 字段遵守 SNI 限制。这意味着攻击者可以复用访客的
|
||||
SNI TLS 连接来访问管理员`虚拟服务`。而 http 响应码 421 的设计目的便是 `Host` SNI 不匹配并且可以用于以上阻止目的。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -573,27 +577,29 @@ spec:
|
|||
## 协议探测 {#protocol-detection}
|
||||
|
||||
Istio 可以[自动确定流量协议](/zh/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection)。
|
||||
但为了避免意外或者有意的误检测，从而导致意外流量行为发生。推荐[显式地声明协议](/zh/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection)。
|
||||
但为了避免意外或者有意的误检测，从而导致意外流量行为发生。
|
||||
推荐[显式地声明协议](/zh/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection)。
|
||||
|
||||
## CNI 网络容器接口 {#CNI}
|
||||
|
||||
为了透明地劫持所以流量， Istio 依赖 通过 `istio-init` `initContainer` 配置 `iptables` 规则。
|
||||
为了透明地劫持所以流量，Istio 依赖 通过 `istio-init` `initContainer` 配置 `iptables` 规则。
|
||||
这增加了一个[要求](/zh/docs/ops/deployment/requirements/)，即需要提供给 Pod `NET_ADMIN`
|
||||
和 `NET_RAW` [兼容性](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)。
|
||||
|
||||
为了减少给予 Pods 的权限， Istio 提供了 [CNI 插件](/zh/docs/setup/additional-setup/cni/)功能，
|
||||
为了减少给予 Pod 的权限，Istio 提供了 [CNI 插件](/zh/docs/setup/additional-setup/cni/)功能，
|
||||
即不再需要以上权限。
|
||||
|
||||
## 使用精简 docker 镜像 {#use-hardened-docker-images}
|
||||
## 使用精简 Docker 镜像 {#use-hardened-docker-images}
|
||||
|
||||
Istio 默认 docker 镜像，包括那些控制面，网关， Sidecar 代理正在使用的镜像，都是基于 `ubuntu`。
|
||||
这提供了多种工具，例如 `bash` 以及 `curl`，这权衡了提供便利和增加攻击接口之间的利弊。
|
||||
Istio 默认 Docker 镜像（包括控制面、网关、Sidecar 代理正在使用的镜像）都是基于 `ubuntu`。
|
||||
这提供了 `bash` 以及 `curl` 等多种工具，权衡了提供便利和增加攻击接口之间的利弊。
|
||||
|
||||
同时 Istio 也提供了更精简的基于 [distroless images](/zh/docs/ops/configuration/security/harden-docker-images/)
|
||||
的镜像，此镜像减少了其中的依赖。
|
||||
同时 Istio 也提供了更精简的、基于
|
||||
[Distroless 镜像](/zh/docs/ops/configuration/security/harden-docker-images/)的镜像，
|
||||
此镜像减少了其中的依赖。
|
||||
|
||||
{{< warning >}}
|
||||
Distroless 镜像目前仍是 alpha 特性。
|
||||
Distroless 镜像目前仍是 Alpha 特性。
|
||||
{{< /warning >}}
|
||||
|
||||
## 发布以及安全策略 {#release-and-security-policy}
|
||||
|
|
@ -608,14 +614,15 @@ Distroless 镜像目前仍是 alpha 特性。
|
|||
|
||||
* 在配置前后均运行 `istioctl analyze` 来确保有效性。
|
||||
* 监测控制面是否有被拒绝配置。被拒绝信息会在日志以及 `pilot_total_xds_rejects` 指标中显示。
|
||||
* 测试您的配置确保出现的是您期待的结果。对于安全策略来说，您可以运行正向和反向的测试来确保您不会意外地对流量进行过多或者过少的约束。
|
||||
* 测试您的配置确保出现的是您期待的结果。
|
||||
对于安全策略来说，您可以运行正向和反向的测试来确保您不会意外地对流量进行过多或者过少的约束。
|
||||
|
||||
## 避免使用 alpha 或者实验阶段特性 {#avoid-alpha-and-experimental-features}
|
||||
## 避免使用 Alpha 或者实验阶段特性 {#avoid-alpha-and-experimental-features}
|
||||
|
||||
所有的 Istio 特性以及 APIs 都定义了[特性阶段](/zh/docs/releases/feature-stages/)，
|
||||
即定义了它的稳定性，弃用策略以及安全策略。
|
||||
|
||||
因为 alpha 以及实验阶段特性没有有力的安全保障，因此推荐尽量避免使用它们。
|
||||
因为 Alpha 以及实验阶段特性没有有力的安全保障，因此推荐尽量避免使用它们。
|
||||
使用这些特性导致的安全问题可能不会马上被修复或者不符合标准[安全漏洞](/zh/docs/releases/security-vulnerabilities/)流程。
|
||||
|
||||
为了确定您集群中使用的特性所在的阶段，请参考 [Istio 特性](/zh/docs/releases/feature-stages/#istio-features)列表。
|
||||
|
|
@ -624,37 +631,37 @@ Distroless 镜像目前仍是 alpha 特性。
|
|||
|
||||
## 锁定的端口 {#lock-down-ports}
|
||||
|
||||
Istio 配置了[一系列锁定的端口](/zh/docs/ops/deployment/requirements/#ports-used-by-istio)为了增强安全性。
|
||||
Istio 配置了[一系列锁定的端口](/zh/docs/ops/deployment/requirements/#ports-used-by-istio)增强安全性。
|
||||
|
||||
### 控制面 {#control-plane}
|
||||
|
||||
Istiod 为了便利暴露了几个未认证的纯本文端口。理想情况下，他们应该被关闭：
|
||||
Istiod 为了便利暴露了几个未认证的明文端口。理想情况下，这些端口应该被关闭：
|
||||
|
||||
* 端口 `8080` 暴露了调试接口，提供了针对集群状态细节的读取权限。
|
||||
这可以通过在 Istiod 设置环境变量 `ENABLE_DEBUG_ON_HTTP=false` 来关闭。警告：许多 `istioctl`
|
||||
命令依赖该接口并且可能无法运行如果该接口被关闭。
|
||||
* 端口 `15010` 将 XDS 服务暴露为纯文本。这可以通过在 Istiod 部署中添加 `--grpcAddr=""` 标示来关闭。
|
||||
注释：高度敏感的服务，例如证书签发和分发服务，绝不允许运行在纯文本上。
|
||||
这可以通过在 Istiod 设置环境变量 `ENABLE_DEBUG_ON_HTTP=false` 来关闭。
|
||||
警告：许多 `istioctl` 命令依赖该接口，如果该接口被关闭这些命令可能无法运行。
|
||||
* 端口 `15010` 将 XDS 服务暴露为明文。这可以通过在 Istiod 部署中添加 `--grpcAddr=""` 标志来关闭。
|
||||
注释：证书签发和分发服务这类高度敏感的服务绝不允许以明文运行。
|
||||
|
||||
### 数据面 {#data-plane}
|
||||
|
||||
代理暴露了一系列端口。暴露给外部的是端口 `15090` (遥测) 和 端口 `15021` (健康检测)。
|
||||
代理暴露了一系列端口。暴露给外部的是端口 `15090`（遥测）和端口 `15021`（健康检测）。
|
||||
端口 `15020` 和 `15000` 提供了调试终端。这两者只暴露给 `localhost`。
|
||||
因此结果是，应用运行在了代理也有访问权限的同一个 Pod 中，即 Sidecar 和应用之间没有信任边界。
|
||||
|
||||
## 配置第三方服务账户 tokens {#configure-third-party-service-account-tokens}
|
||||
|
||||
为了认证 Istio 数据面， Istio 代理使用服务账户 tokens。 Kubernetes 支持两种类型的 tokens ：
|
||||
为了认证 Istio 数据面，Istio 代理使用服务账户 token。Kubernetes 支持两种类型的 token：
|
||||
|
||||
* 第三方 tokens，拥有有范围限制的受众以及有效期。
|
||||
* 第一方 tokens，没有有效期以及挂在到全部 Pods 上。
|
||||
* 第三方 token，拥有有范围限制的受众以及有效期。
|
||||
* 第一方 token，没有有效期以及挂载到全部 Pod 上。
|
||||
|
||||
因为第一方 token 的性质较为不安全， Istio 默认使用第三方 tokens。但是该特性并未在全部的 Kubernetes 平台上启用。
|
||||
因为第一方 token 的性质较为不安全，Istio 默认使用第三方 token。但是该特性并未在全部的 Kubernetes 平台上启用。
|
||||
|
||||
如果您使用 `istioctl` 来安装，将会自动检测是否支持第三方 tokens。同时这也可以进行手动配置
|
||||
`--set values.global.jwtPolicy=third-party-jwt` 或 `--set values.global.jwtPolicy=first-party-jwt`。
|
||||
如果您使用 `istioctl` 来安装，将会自动检测是否支持第三方 token。同时这也可以通过传递
|
||||
`--set values.global.jwtPolicy=third-party-jwt` 或 `--set values.global.jwtPolicy=first-party-jwt` 进行手动配置。
|
||||
|
||||
为了确定您的集群是否支持第三方 tokens，可以查找 `TokenRequest` API。如果没有得到以下回复，那么该特性尚未支持：
|
||||
为了确定您的集群是否支持第三方 token，可以查找 `TokenRequest` API。如果没有得到以下响应，那么尚未支持该特性：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))'
|
||||
|
|
@ -676,9 +683,9 @@ $ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceac
|
|||
|
||||
## 配置下游连接数限制 {#configure-a-limit-on-downstream-connections}
|
||||
|
||||
默认情况，Istio（以及 Envoy）没有对下游连接数的限制。但这可能被恶意活动所利用(见
|
||||
[security bulletin 2020-007](/zh/news/security/istio-security-2020-007/))。
|
||||
为了解决，您需要在您的环境中配置合适的连接数限制。
|
||||
默认情况，Istio（以及 Envoy）没有对下游连接数的限制。但这可能被恶意活动所利用
|
||||
（参见 [security bulletin 2020-007](/zh/news/security/istio-security-2020-007/)）。
|
||||
为了解决此问题，您需要在您的环境中配置合适的连接数限制。
|
||||
|
||||
### 配置 `global_downstream_max_connections` 值 {#configure-global_downstream_max_connections-value}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue