安全最佳实践

 22 分钟阅读  

Istio 安全功能提供强大的身份、策略、透明的 TLS 加密以及身份验证、授权和审计 (AAA) 工具来保护您的服务和数据。但是，为了安全地充分利用这些功能，必须注意遵循最佳实践。建议在继续操作之前查看安全概述。

双向 TLS

Istio 将在可能的情况下自动使用双向 TLS加密流量。但是，代理默认情况下配置为宽松模式，这意味着它们将接受双向 TLS 和明文流量。

虽然这对于增量采用或允许来自没有 Istio sidecar 的客户端的流量是必需的，但它也会削弱安全立场。建议在可能的情况下迁移到严格模式，以强制使用双向 TLS。

但是，仅靠双向 TLS 并不总是足以完全保护流量，因为它仅提供身份验证，而不提供授权。这意味着任何拥有有效证书的人仍然可以访问服务。

为了完全锁定流量，建议配置授权策略。这些策略允许创建细粒度的策略以允许或拒绝流量。例如，您可以仅允许来自 app 命名空间的请求访问 hello-world 服务。

授权策略

Istio 授权在 Istio 安全中起着至关重要的作用。配置正确的授权策略以最大程度地保护您的集群需要付出努力。了解这些配置的影响非常重要，因为 Istio 无法确定所有用户的正确授权。请完整遵循本节内容。

更安全的授权策略模式

使用默认拒绝模式

我们建议您按照默认拒绝模式定义您的 Istio 授权策略，以增强集群的安全态势。默认拒绝授权模式意味着您的系统默认拒绝所有请求，并且您定义允许请求的条件。如果您错过了一些条件，则流量将被意外拒绝，而不是意外允许。后者通常是安全事件，而前者可能导致用户体验不佳、服务中断或不符合您的 SLO/SLA。

例如，在HTTP 流量的授权任务中，名为 allow-nothing 的授权策略确保默认情况下所有流量都被拒绝。从那里，其他授权策略根据特定条件允许流量。

使用ALLOW-with-positive-matching 和 DENY-with-negative-match 模式

尽可能使用 ALLOW-with-positive-matching 或 DENY-with-negative-matching 模式。这些授权策略模式更安全，因为在策略不匹配的情况下，最糟糕的结果是意外的 403 拒绝，而不是授权策略绕过。

ALLOW-with-positive-matching 模式是仅将 ALLOW 操作与正向匹配字段（例如 paths、values）一起使用，并且不使用任何负向匹配字段（例如 notPaths、notValues）。

DENY-with-negative-matching 模式是仅将 DENY 操作与负向匹配字段（例如 notPaths、notValues）一起使用，并且不使用任何正向匹配字段（例如 paths、values）。

例如，以下授权策略使用 ALLOW-with-positive-matching 模式允许对路径 /public 的请求

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/public"]

上述策略显式列出了允许的路径（/public）。这意味着请求路径必须与 /public 完全相同才能允许请求。任何其他请求都将被默认拒绝，从而消除了未知规范化行为导致策略绕过的风险。

以下是使用 DENY-with-negative-matching 模式实现相同结果的示例

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: DENY
  rules:
  - to:
    - operation:
        notPaths: ["/public"]

了解授权策略中的路径规范化

授权策略的执行点是 Envoy 代理，而不是后端应用程序中的常规资源访问点。当 Envoy 代理和后端应用程序对请求的解释不同时，就会发生策略不匹配。

不匹配可能导致意外拒绝或策略绕过。后者通常是需要立即修复的安全事件，这也是为什么我们需要在授权策略中进行路径规范化的原因。

例如，考虑一个拒绝路径为 /data/secret 的请求的授权策略。路径为 /data//secret 的请求不会被拒绝，因为它与授权策略中定义的路径不匹配，因为路径中有多余的正斜杠 /。

请求通过，然后后端应用程序返回与路径 /data/secret 返回相同的响应，因为后端应用程序将路径 /data//secret 规范化为 /data/secret，因为它认为双正斜杠 // 等效于单个正斜杠 /。

在此示例中，策略执行点（Envoy 代理）对路径的理解与资源访问点（后端应用程序）不同。不同的理解导致了不匹配，随后导致授权策略被绕过。

由于以下因素，这成为一个复杂的问题

  • 缺乏规范化的明确标准。

  • 不同层中的后端和框架有其自己的特殊规范化。

  • 应用程序甚至可以为其自身用例进行任意规范化。

Istio 授权策略实现了各种基本规范化选项的内置支持，以帮助您更好地解决问题

关于配置路径规范化选项的指南

案例 1：您根本不需要规范化

在深入了解配置规范化的细节之前，您应该首先确保需要规范化。

如果您不使用授权策略，或者您的授权策略不使用任何 path 字段，则不需要规范化。

如果您的所有授权策略都遵循更安全的授权模式，在最坏的情况下会导致意外拒绝而不是策略绕过，则您可能不需要规范化。

案例 2：您需要规范化，但不确定使用哪种规范化选项

您需要规范化，但不知道使用哪个选项。最安全的做法是最严格的规范化选项，它在授权策略中提供最大级别的规范化。

这通常是由于复杂的多层系统使得实际上不可能弄清楚请求超出执行点后实际发生了什么规范化。

如果它已经满足您的要求并且您确定其含义，则可以使用不太严格的规范化选项。

对于这两个选项，请确保您专门针对您的需求编写正向和负向测试，以验证规范化是否按预期工作。这些测试有助于捕获由于对规范化发生在您的请求中的误解或了解不完整而导致的潜在绕过问题。

请参阅在路径规范化上自定义您的系统，以详细了解如何配置规范化选项。

案例 3：您需要不受支持的规范化选项

如果您需要 Istio 尚未支持的特定规范化选项，请遵循不受支持的规范化的缓解措施以获取自定义规范化支持或为 Istio 社区创建功能请求。

在路径规范化上自定义您的系统

Istio 授权策略可以基于 HTTP 请求中的 URL 路径。路径规范化（又名 URI 规范化）修改和标准化传入请求的路径，以便以标准方式处理规范化路径。在路径规范化之后，语法上不同的路径可能等效。

在根据授权策略评估和路由请求之前，Istio 支持对请求路径执行以下规范化方案

选项描述示例
NONE不执行任何规范化。Envoy 收到的任何内容都将按原样转发到任何后端服务。../%2Fa../b 由授权策略评估并发送到您的服务。
BASE这目前是 Istio 的默认安装中使用的选项。这将对 Envoy 代理应用normalize_path选项，该选项遵循RFC 3986并进行额外的规范化以将反斜杠转换为正斜杠。/a/../b 规范化为 /b。\da 规范化为 /da。
MERGE_SLASHES在BASE规范化后合并斜杠。/a//b 规范化为 /a/b。
DECODE_AND_MERGE_SLASHES当您默认允许所有流量时的最严格设置。建议使用此设置，但需要注意的是，您需要彻底测试您的授权策略路由。百分比编码的斜杠和反斜杠字符（%2F、%2f、%5C 和 %5c）在 MERGE_SLASHES 规范化之前解码为 / 或 \。/a%2fb 规范化为 /a/b。

需要强调的是，规范化算法按以下顺序执行

  1. 百分比解码 %2F、%2f、%5C 和 %5c。
  2. Envoy 中实现的RFC 3986和其他规范化normalize_path选项。
  3. 合并斜杠

有关支持的规范化的完整列表，请参阅授权策略规范化。

配置示例

确保 Envoy 规范化请求路径以匹配后端服务的预期对于系统的安全性至关重要。以下示例可作为您配置系统的参考。规范化的 URL 路径，或者如果选择NONE则为原始 URL 路径将

  1. 用于检查授权策略
  2. 转发到后端应用程序
您的应用程序…选择…
依赖代理进行规范化BASE、MERGE_SLASHES 或 DECODE_AND_MERGE_SLASHES
基于RFC 3986规范化请求路径，并且不合并斜杠

BASE
根据RFC 3986规范化请求路径，合并斜杠，但不解码百分比编码的斜杠。MERGE_SLASHES
根据RFC 3986规范化请求路径，解码百分比编码的斜杠并合并斜杠。DECODE_AND_MERGE_SLASHES
以一种与RFC 3986不兼容的方式处理请求路径。NONE

如何配置

您可以使用istioctl更新网格配置。

$ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES

或者通过修改您的操作符覆盖文件。

$ cat <<EOF > iop.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    pathNormalization:
      normalization: DECODE_AND_MERGE_SLASHES
EOF
$ istioctl install -f iop.yaml

或者，如果您想直接编辑网格配置，可以将pathNormalization添加到网格配置中，该配置是istio-system命名空间中的istio-<REVISION_ID> ConfigMap。例如，如果您选择DECODE_AND_MERGE_SLASHES选项，则可以修改网格配置如下所示。

apiVersion: v1
  data:
    mesh: |-
      ...
      pathNormalization:
        normalization: DECODE_AND_MERGE_SLASHES
      ...

不受支持的规范化的缓解措施

本节介绍了针对不受支持的规范化的各种缓解措施。当您需要 Istio 不支持的特定规范化时，这些措施可能会有用。

请确保您彻底了解缓解措施并谨慎使用，因为某些缓解措施依赖于 Istio 范围之外且 Istio 不支持的事物。

自定义规范化逻辑

您可以使用 WASM 或 Lua 过滤器应用自定义规范化逻辑。建议使用 WASM 过滤器，因为它得到官方支持，并且 Istio 也使用它。您可以使用 Lua 过滤器进行快速概念验证 DEMO，但我们不建议在生产环境中使用 Lua 过滤器，因为它不受 Istio 支持。

自定义规范化示例（大小写规范化）

在某些环境中，可能需要以不区分大小写的方式比较授权策略中的路径。例如，将https://myurl/get和https://myurl/GeT视为等效。

在这些情况下，可以使用以下所示的EnvoyFilter插入一个 Lua 过滤器将路径规范化为小写。此过滤器将更改用于比较的路径和呈现给应用程序的路径。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_FIRST
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end

编写主机匹配策略

Istio 会为主机名本身和所有匹配的端口生成主机名。例如，example.com主机的虚拟服务或网关会生成与example.com和example.com:*匹配的配置。但是，精确匹配授权策略仅匹配hosts或notHosts字段中给出的精确字符串。

授权策略规则匹配主机应使用前缀匹配而不是精确匹配编写。例如，对于与为example.com主机名生成的 Envoy 配置匹配的AuthorizationPolicy，您将使用hosts: ["example.com", "example.com:*"]，如下面的AuthorizationPolicy所示。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ingress-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["example.com", "example.com:*"]

此外，host和notHosts字段通常应仅用于网关，用于进入网格的外部流量，而不应用于服务网格内流量的 Sidecar。这是因为服务器端（执行授权策略的位置）上的 Sidecar 在将请求重定向到应用程序时不使用Host标头。这使得 Sidecar 上的host和notHost毫无意义，因为客户端可以使用显式 IP 地址和任意Host标头而不是服务名称来访问应用程序。

如果您确实需要出于任何原因在 Sidecar 上基于Host标头执行访问控制，请遵循默认拒绝模式，如果客户端使用任意Host标头，则该模式将拒绝请求。

专业 Web 应用防火墙 (WAF)

许多专门的 Web 应用防火墙 (WAF) 产品提供了额外的规范化选项。它们可以部署在 Istio 入口网关前面，以规范化进入网格的请求。然后将在规范化的请求上执行授权策略。请参阅您特定的 WAF 产品以配置规范化选项。

Istio 功能请求

如果您认为 Istio 应该正式支持特定的规范化，您可以按照报告漏洞页面向 Istio 产品安全工作组发送关于特定规范化的功能请求，以进行初步评估。

请勿在未先联系 Istio 产品安全工作组的情况下在公开场合打开任何问题，因为该问题可能被视为需要私下修复的安全漏洞。

如果 Istio 产品安全工作组评估功能请求不是安全漏洞，则将在公开场合打开一个问题，以进一步讨论功能请求。

已知限制

本节列出了授权策略的已知限制。

不支持服务器优先 TCP 协议

服务器优先 TCP 协议意味着服务器应用程序将在接受 TCP 连接后立即发送第一个字节，然后再接收来自客户端的任何数据。

目前，授权策略仅支持对入站流量执行访问控制，而不支持出站流量。

它也不支持服务器优先 TCP 协议，因为服务器应用程序甚至在收到来自客户端的任何数据之前就会发送第一个字节。在这种情况下，服务器发送的初始第一个字节将直接返回给客户端，而不会经过授权策略的访问控制检查。

如果服务器优先 TCP 协议发送的第一个字节包含任何需要通过适当授权来保护的敏感数据，则不应使用授权策略。

如果第一个字节不包含任何敏感数据，例如，第一个字节用于协商与任何客户端都公开可用的数据连接，则您仍然可以在这种情况下使用授权策略。授权策略将照常处理客户端在第一个字节之后发送的后续请求。

了解流量捕获限制

Istio Sidecar 通过捕获入站流量和出站流量并将它们通过 Sidecar 代理来工作。

但是，并非所有流量都会被捕获。

  • 重定向仅处理基于 TCP 的流量。任何 UDP 或 ICMP 数据包都不会被捕获或修改。
  • 在许多Sidecar 使用的端口以及端口 22 上禁用了入站捕获。此列表可以通过traffic.sidecar.istio.io/excludeInboundPorts等选项进行扩展。
  • 类似地，可以通过traffic.sidecar.istio.io/excludeOutboundPorts等设置或其他方法减少出站捕获。

通常，应用程序与其 Sidecar 代理之间存在最小的安全边界。允许在每个 Pod 基础上配置 Sidecar，并且两者都在同一个网络/进程命名空间中运行。因此，应用程序可能能够删除重定向规则并删除、更改、终止或替换 Sidecar 代理。这允许 Pod 故意绕过其 Sidecar 进行出站流量，或故意允许入站流量绕过其 Sidecar。

因此，依赖 Istio 无条件捕获所有流量是不安全的。相反，安全边界是客户端可能无法绕过其他 Pod 的 Sidecar。

例如，如果我在端口9080上运行reviews应用程序，我可以假设来自productpage应用程序的所有流量都将被 Sidecar 代理捕获，Istio 身份验证和授权策略可能会应用于此流量。

使用NetworkPolicy 进行纵深防御

为了进一步保护流量，可以将 Istio 策略与 Kubernetes网络策略结合使用。这使得能够使用强大的纵深防御策略，可以用来进一步加强网格的安全。

例如，您可以选择仅允许流量访问我们的reviews应用程序的端口9080。如果集群中存在受损的 Pod 或安全漏洞，这可能会限制或阻止攻击者的进展。

根据实际实现，对网络策略的更改可能不会影响 Istio 代理中的现有连接。您可能需要在应用策略后重新启动 Istio 代理，以便关闭现有连接，并且新连接将受新策略约束。

保护出口流量

一个常见的误解是，诸如outboundTrafficPolicy: REGISTRY_ONLY之类的选项充当安全策略，阻止对所有未声明服务的访问。但是，正如上面提到的，这不是一个强大的安全边界，应该被视为尽力而为。

虽然这对于防止意外依赖关系很有用，但如果您想保护出站流量并强制所有出站流量都通过代理，则应改为依靠出口网关。与网络策略结合使用时，您可以强制所有流量或某些子集通过出口网关。这确保了即使客户端意外或恶意绕过了其 Sidecar，请求也会被阻止。

在使用 TLS 发起时，在目标规则中配置 TLS 验证

Istio 提供了从 Sidecar 代理或网关发起 TLS的功能。这使得发送纯文本 HTTP 流量的应用程序能够透明地“升级”到 HTTPS。

配置DestinationRule的tls设置以指定caCertificates、subjectAltNames和sni字段时，必须小心。可以通过在 Istiod 上启用环境变量VERIFY_CERTIFICATE_AT_CLIENT=true来自系统证书存储的 CA 证书自动设置caCertificate。如果仅对选定的主机需要自动使用的操作系统 CA 证书，则在 Istiod 上设置环境变量VERIFY_CERTIFICATE_AT_CLIENT=false，可以在所需的DestinationRule(s)中将caCertificates设置为system。在DestinationRule中指定caCertificates将优先，并且不会使用 OS CA 证书。默认情况下，出站流量在 TLS 握手期间不会发送 SNI。必须在DestinationRule中设置 SNI 以确保主机正确处理请求。

例如

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: google-tls
spec:
  host: google.com
  trafficPolicy:
    tls:
      mode: SIMPLE
      caCertificates: /etc/ssl/certs/ca-certificates.crt
      subjectAltNames:
      - "google.com"
      sni: "google.com"

网关

在运行 Istio网关时，会涉及一些资源。

  • Gateway，它控制网关的端口和 TLS 设置。
  • VirtualService 控制路由逻辑。它们通过在 gateways 字段中直接引用 Gateway 并在 Gateway 和 VirtualService 中的 hosts 字段上达成共识来关联。

限制Gateway 创建权限

建议将 Gateway 资源的创建限制为可信的集群管理员。这可以通过 Kubernetes RBAC 策略 或 Open Policy Agent 等工具来实现。

避免过于宽泛的hosts 配置

尽可能避免在 Gateway 中使用过于宽泛的 hosts 设置。

例如，此配置将允许任何 VirtualService 绑定到 Gateway，这可能会暴露意外的域名

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "*"

应将其锁定，以仅允许特定域名或特定命名空间。

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "foo.example.com" # Allow only VirtualServices that are for foo.example.com
  - "default/bar.example.com" # Allow only VirtualServices in the default namespace that are for bar.example.com
  - "route-namespace/*" # Allow only VirtualServices in the route-namespace namespace for any host

隔离敏感服务

可能需要对敏感服务实施更严格的物理隔离。例如，您可能希望为敏感的 payments.example.com 运行一个 专用的网关实例，同时为不太敏感的域名（如 blog.example.com 和 store.example.com）利用单个共享网关实例。这可以提供更强大的纵深防御，并有助于满足某些法规遵从性准则。

显式禁用在宽松的 SNI 主机匹配下所有敏感的 http 主机

使用多个 Gateway 来定义不同主机上的双向 TLS 和简单 TLS 是合理的。例如，对 SNI 主机 admin.example.com 使用双向 TLS，对 SNI 主机 *.example.com 使用简单 TLS。

kind: Gateway
metadata:
  name: guestgateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*.example.com"
    tls:
      mode: SIMPLE
---
kind: Gateway
metadata:
  name: admingateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - admin.example.com
    tls:
      mode: MUTUAL

如果需要上述操作，强烈建议在连接到 *.example.com 的 VirtualService 中显式禁用 http 主机 admin.example.com。原因是当前底层的 envoy 代理不需要遵循 SNI 约束的 http 1 标头 Host 或 http 2 伪标头 :authority，攻击者可以重用访客 SNI TLS 连接来访问 admin VirtualService。http 响应代码 421 是为这种 Host SNI 不匹配而设计的，可用于实现禁用。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: disable-sensitive
spec:
  hosts:
  - "admin.example.com"
  gateways:
  - guestgateway
  http:
  - match:
    - uri:
        prefix: /
    fault:
      abort:
        percentage:
          value: 100
        httpStatus: 421
    route:
    - destination:
        port:
          number: 8000
        host: dest.default.cluster.local

协议检测

Istio 将 自动确定它看到的流量的协议。为了避免意外或故意错误检测，这可能导致意外的流量行为，建议 显式声明协议（如果可能）。

CNI

为了透明地捕获所有流量，Istio 依赖于由 istio-init initContainer 配置的 iptables 规则。这增加了对 NET_ADMIN 和 NET_RAW 功能 的 要求，以便 Pod 可以使用这些功能。

为了减少授予 Pod 的权限，Istio 提供了一个 CNI 插件，该插件消除了此要求。

使用加固的 Docker 镜像

Istio 的默认 Docker 镜像（包括控制平面、网关和 sidecar 代理运行的镜像）基于 ubuntu。这提供了各种工具，例如 bash 和 curl，这些工具以牺牲便利性为代价增加了攻击面。

Istio 还提供了一个基于 无发行版镜像 的较小镜像，该镜像减少了镜像中的依赖项。

发布和安全策略

为了确保您的集群拥有针对已知漏洞的最新安全补丁，务必使用 Istio 的最新补丁版本，并确保您使用的是仍在接收安全补丁的 受支持版本。

检测无效配置

虽然 Istio 在创建资源时会提供资源验证，但这些检查无法捕获所有问题，从而阻止配置在网格中分发。这可能导致应用意外被忽略的策略，从而导致意外结果。

  • 在应用配置之前或之后运行 istioctl analyze 以确保其有效。
  • 监视控制平面以获取被拒绝的配置。除了日志之外，这些配置还通过 pilot_total_xds_rejects 指标公开。
  • 测试您的配置以确保其产生预期的结果。对于安全策略，运行正向和反向测试以确保您不会意外地限制过多或过少的流量非常有用。

避免使用 alpha 和实验性功能

所有 Istio 功能和 API 都分配了一个 功能状态，定义其稳定性、弃用策略和安全策略。

由于 alpha 和实验性功能没有那么强的安全保证，因此建议尽可能避免使用它们。在这些功能中发现的安全问题可能不会立即修复，或者不遵循我们的标准 安全漏洞 流程。

要确定集群中正在使用的功能的功能状态，请查阅 Istio 功能 列表。

锁定端口

Istio 配置了 各种端口，可以将其锁定以提高安全性。

控制平面

默认情况下，Istiod 公开了几个未经身份验证的明文端口以方便使用。如果需要，可以关闭这些端口。

  • 端口 8080 公开了调试接口，该接口提供了对有关集群状态的各种详细信息的读取访问权限。可以通过在 Istiod 上设置环境变量 ENABLE_DEBUG_ON_HTTP=false 来禁用它。警告：许多 istioctl 命令依赖于此接口，如果禁用它，则这些命令将无法正常工作。
  • 端口 15010 通过明文公开 XDS 服务。可以通过向 Istiod 部署添加 --grpcAddr="" 标志来禁用它。注意：高度敏感的服务（例如证书签名和分发服务）绝不会通过明文提供服务。

数据平面

代理公开了各种端口。外部公开的端口有 15090（遥测）和 15021（健康检查）。端口 15020 和 15000 提供调试端点。这些仅通过 localhost 公开。因此，在与代理相同的 Pod 中运行的应用程序可以访问；sidecar 和应用程序之间没有信任边界。

配置第三方服务帐户令牌

要对 Istio 控制平面进行身份验证，Istio 代理将使用服务帐户令牌。Kubernetes 支持这两种形式的令牌

  • 第三方令牌，具有范围受限的受众和过期时间。
  • 第一方令牌，没有过期时间，并挂载到所有 Pod 中。

由于第一方令牌的属性安全性较低，因此 Istio 将默认使用第三方令牌。但是，此功能并非在所有 Kubernetes 平台上都启用。

如果您使用 istioctl 进行安装，则将自动检测支持。这也可以手动完成，并通过传递 --set values.global.jwtPolicy=third-party-jwt 或 --set values.global.jwtPolicy=first-party-jwt 进行配置。

要确定您的集群是否支持第三方令牌，请查找 TokenRequest API。如果这返回无响应，则表示不支持此功能。

$ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))'

{
    "name": "serviceaccounts/token",
    "singularName": "",
    "namespaced": true,
    "group": "authentication.k8s.io",
    "version": "v1",
    "kind": "TokenRequest",
    "verbs": [
        "create"
    ]
}

虽然大多数云提供商现在都支持此功能，但许多本地开发工具和自定义安装在 Kubernetes 1.20 之前可能不支持。要启用此功能，请参阅 Kubernetes 文档。

配置下游连接限制

默认情况下，Istio（和 Envoy）对下游连接的数量没有限制。恶意行为者可以利用这一点（请参阅 安全公告 2020-007）。要解决此问题，您必须为您的环境配置适当的连接限制。

配置 global_downstream_max_connections 值

可以在安装期间提供以下配置

meshConfig:
  defaultConfig:
    runtimeValues:
      "overload.global_downstream_max_connections": "100000"
这些信息是否有用？
您对改进有任何建议吗？

感谢您的反馈！