1.2. Service Mesh 发行注记

在这个版本中，除了复制注解外，您还可以为 OpenShift 路由复制特定的标签。Red Hat OpenShift Service Mesh 将 Istio 网关资源中存在的所有标签和注解（从 kubectl.kubernetes.io 开始的注解除外）复制到受管 OpenShift Route 资源中。

此发行版本添加了对 WasmPlugin API 的支持，并弃用了 ServiceMeshExtention API。

此发行版本引进了对 AWS(ROSA)上的 Red Hat OpenShift 的服务网格支持，包括多集群联邦。

在此发行版本中，istio-node DaemonSet 被重命名为 istio-cni-node，以匹配上游 Istio 中的名称。

Istio 1.10 更新了 Envoy，默认使用 eth0 而不是 lo 将流量发送到应用程序容器。

对于所有平台，此发行版本结束了对基于 Service Mesh 1.1 的 Service Mesh Control Planes 的支持。

Service Mesh 2.2 基于 Istio 1.12，它带来新功能和产品改进。虽然仍然会支持许多 Istio 1.12 功能，但请注意以下不被支持的功能：

Kubernetes Gateway API 是一个技术预览功能，默认为禁用。

要启用这个功能，请在 ServiceMeshControlPlane 中为 Istiod 容器设置以下环境变量：

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: true
            PILOT_ENABLE_GATEWAY_API_STATUS: true
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: true

使用 SameNamespace 或 All 设置在 Gateway API 监听器上限制路由附加功能可能。Istio 会忽略 listeners.allowedRoutes.namespaces 中标签选择器的使用，并恢复到默认行为 (SameNamespace)。

Red Hat OpenShift Service Mesh 自动在 Service Mesh control plane 和应用程序命名空间中创建和管理多个 NetworkPolicies 资源。这是为了确保应用程序和 control plane 可以相互通信。

如果要禁用自动创建和管理 NetworkPolicies 资源，例如为了强制执行公司安全策略，您可以编辑 ServiceMeshControlPlane，将 spec.security.manageNetworkPolicy 设置设置为 false

添加了新的自定义资源定义(CRD)以支持联邦服务网格（federating service mesh）。服务网格可以整合到同一集群中或跨不同的 OpenShift 集群。这些新资源包括：

在 AWS(ROSA)、Azure Red Hat OpenShift(ARO)或 OpenShift Dedicated(OSD)上的 Red Hat OpenShift Service 上的集群间不支持 Service Mesh Federation。

OVN-Kubernetes Container Network Interface(CNI)以前在 Red Hat OpenShift Service Mesh 2.0.1 中作为技术预览功能引进，现在包括在 Red Hat OpenShift Service Mesh 2.1 和 2.0.x 中，用于 OpenShift Container Platform 4.7.32、OpenShift Container Platform 4.8.12 和 OpenShift Container Platform 4.9。

ServiceMeshExtensions 自定义资源定义(CRD)现已正式发布，它首次作为技术预览功能在版本 2.0 中推出。您可以使用 CRD 构建自己的插件，但红帽并不支持您创建的插件。

在 Service Mesh 2.1 中已完全删除 Mixer。如果启用了 Mixer，则会阻止从 Service Mesh 2.0.x 升级到 2.1。混合器插件需要移植到 WebAssembly 扩展。

Mixer 现已正式删除，OpenShift Service Mesh 2.1 不支持 3scale 混合器适配器。在升级到 Service Mesh 2.1 之前，删除基于 Mixer 的 3scale 适配器和任何其他 Mixer 插件。然后，使用 Service MeshExtension 资源手动安装和配置使用 Service Mesh 2.1+ 的新 3scale WebAssembly 适配器。

3scale 2.11 引入了基于 WebAssembly 的更新 Service Mesh 集成。

Service Mesh 2.1 基于 Istio 1.9，它带来了大量新功能和产品增强。虽然大多数 Istio 1.9 功能被支持，但请注意以下例外：

Red Hat OpenShift Service Mesh 在每个 ServiceMeshControlPlane 协调结束时用于修剪旧资源的时间已经减少。这会更快地进行 ServiceMeshControlPlane 部署，并允许应用到现有 SMCP 的更改更快地生效。

Kiali 1.36 包括以下功能和增强：

Red Hat OpenShift Service Mesh 包含一个可远程利用的漏洞 CVE-2021-39156，其中 HTTP 请求带有片段（以 # 字符开头的 URI 末尾的一个部分），您可以绕过 Istio URI 基于路径的授权策略。例如，Istio 授权策略拒绝发送到 URI 路径 /user/profile 的请求。在存在安全漏洞的版本中，带有 URI 路径 /user/profile#section1 的请求绕过拒绝策略并路由到后端（通过规范的 URI path /user/profile%23section1），可能会导致安全事件。

如果您使用带有 DENY 操作和 operation.paths 的授权策略，或者 ALLOW 操作和 operation.notPaths，则会受到此漏洞的影响。

在这个版本中，在授权和路由前会删除请求的 URI 片段部分。这可以防止其 URI 中带有片段的请求绕过基于 URI 且没有片段部分的授权策略。

要从缓解措施中的新行为中选择，将保留 URI 的片段部分。您可以将 ServiceMeshControlPlane 配置为保留 URI 片段。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

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

如果您使用精确字符串比较的 AuthorizationPolicy 来确定 主机或非主机，则会影响您的集群。

您必须更新授权策略 规则，以使用前缀匹配而不是完全匹配。例如，在第一个 AuthorizationPolicy 示例中，将 hosts: ["httpbin.com"] 替换为 hosts: ["httpbin.com:*"]。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

Istio 包含一个可被远程利用的漏洞，当使用基于路径的授权规则时，带有多个斜杠或转义的斜杠字符（%2F 或 %5C）的 HTTP 请求路径可能会绕过 Istio 授权策略。

例如，假设 Istio 集群管理员定义了一个授权 DENY 策略，以便在路径 /admin 上拒绝请求。发送到 URL 路径 //admin 的请求不会被授权策略拒绝。

根据 RFC 3986，带有多个斜杠的路径 //admin 在技术上应被视为与 /admin 不同的路径。但是，一些后端服务选择通过将多个斜杠合并成单斜杠来规范 URL 路径。这可能导致绕过授权策略（//admin 不匹配 /admin），用户可以在后端的路径 /admin 上访问资源，这可能会产生安全问题。

如果您使用 ALLOW action + notPaths 字段或者 DENY action + paths 字段特征，您的集群会受到这个漏洞的影响。这些模式可能会被意外的策略绕过。

在以下情况下，集群不会受到此漏洞的影响：

Istio 授权策略可能基于 HTTP 请求中的 URL 路径。路径规范化 （也称为 URI 规范化）、修改和标准化传入请求的路径，以便能够以标准的方式处理规范化路径。在路径规范化后，同步不同路径可能是等同的。

Istio 在根据授权策略和路由请求前，支持请求路径中的以下规范化方案：

规范化算法按以下顺序进行：

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

要为 Red Hat OpenShift Service Mesh 配置路径规范化，请在 ServiceMeshControlPlane 中指定以下内容。使用配置示例来帮助确定您的系统设置。

spec:
  techPreview:
    global:
      pathNormalization: <option>

在某些环境中，在授权策略中对路径进行比较时不区分大小写可能很有用。例如，把 https://myurl/get 视为与 https://myurl/GeT 一样。在这些情况下，您可以使用如下所示的 EnvoyFilter。此过滤器将更改用于比较的路径以及应用程序显示的路径。在本例中，istio-system 是 Service Mesh control plane 项目的名称。

将 EnvoyFilter 保存到文件中并运行以下命令：

$ oc create -f <myEnvoyFilterFile>

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"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      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