1.11.4.4.2. 配置 2.0 ServiceMeshControlPlane
为 Red Hat OpenShift Service Mesh 版本 2.0 更改了 ServiceMeshControlPlane 资源。创建 ServiceMeshControlPlane 资源 v2 版本后，修改该资源以利用新功能并适合您的部署。在修改 ServiceMeshControlPlane 资源时，考虑对 Red Hat OpenShift Service Mesh 2.0 规范和行为进行以下更改。您还可以参阅 Red Hat OpenShift Service Mesh 2.0 产品文档来获取您使用的功能的新信息。v2 资源必须用于 Red Hat OpenShift Service Mesh 2.0 安装。
1.11.4.4.2.1. 构架更改
之前的版本使用的架构单元已被 Istiod 替代。在 2.0 中，Service Mesh control plane 组件 Mixer、Pilot、Citadel、Galley 和 sidecar 注入程序功能已合并为一个组件 Istiod。
虽然 Mixer 不再作为 control plane 组件支持，但 Mixer 策略和遥测插件现在可以通过 Istiodi 中的 WASM 扩展支持。如果您需要集成旧的 Mixer 插件，则可为策略和遥测启用混合程序。
安全发现服务 Service（SDS）用于直接从 Istiod 向 sidecar 分发证书和密钥。在 Red Hat OpenShift Service Mesh 1.1 中，secret 由 Citadel 生成，代理使用它来检索其客户端证书和密钥。
1.11.4.4.2.2. 注解更改
v2.0 不再支持以下注解。如果使用其中一个注解，则必须更新工作负载，然后才能将其移到 v2.0 Service Mesh control plane。
-
sidecar.maistra.io/proxyCPULimit已被sidecar.istio.io/proxyCPULimit替代。如果您在工作负载上使用sidecar.maistra.io注解，则必须修改这些工作负载，使其使用相应的sidecar.istio.io。 -
sidecar.maistra.io/proxyMemoryLimit已替换为sidecar.istio.io/proxyMemoryLimit -
不再支持
sidecar.istio.io/discoveryAddress。另外，默认发现地址已经从pilot.<control_plane_namespace>.svc:15010（如果启用 mtls，使用端口 15011）变为istiod-<smcp_name>.<control_plane_namespace>.svc:15012。 -
健康状态端口不再可以被配置，它被硬编码为 15021。* 如果您要定义自定义状态端口，如
status.sidecar.istio.io/port，则必须在将工作负载移至 v2.0 Service Mesh control plane 前删除覆盖。就绪度检查仍然可以通过将状态端口设置为0来禁用。 - Kubernetes Secret 资源不再用于为 sidecar 发布客户端证书。证书现在通过 Istiod 的 SDS 服务发布。如果您依赖挂载的 secret，则 v2.0 Service Mesh control plane 中的工作负载将无法使用它们。
1.11.4.4.2.3. 行为更改
Red Hat OpenShift Service Mesh 2.0 中的一些功能与之前的版本不同。
-
网关上的就绪度端口已从
15020移到15021。 - 目标主机可见性包括 VirtualService 以及 ServiceEntry 资源。它包括所有通过 Sidecar 资源实施的限制。
- 默认启用自动 mutual TLS。代理到代理通信会自动配置为使用 mTLS，而不管是否有全局的验证策略。
-
代理与 Service Mesh control plane 通讯时，无论
spec.security.controlPlane.mtls设置如何，都始终使用安全连接。spec.security.controlPlane.mtls设置仅在配置 Mixer 遥测或策略的连接时使用。
1.11.4.4.2.4. 不支持资源的迁移详情
Policy（策略） （authentication.istio.io/v1alpha1）不再被支持。
策略资源必须迁移到 v2.0 Service Mesh control planes、PeerAuthentication 和 RequestAuthentication 的新资源类型。根据策略资源中的具体配置，您可能需要配置多个资源来达到同样效果。
双向 TLS
使用 security.istio.io/v1beta1 PeerAuthentication 资源可以实现双向 TLS 强制。传统的 spec.peers.mtls.mode 字段会直接映射到新资源的 spec.mtls.mode 字段。选择条件已从在 spec.targets[x].name 中指定服务名称改为 spec.selector.matchLabels 中的标签选择器。在 PeerAuthentication 中，标签必须与目标列表中指定的服务选择器匹配。任何特定于端口的设置都需要映射到 spec.portLevelMtls。
身份验证
在 spec.origins 中指定的附加验证方法必须映射到 security.istio.io/v1beta1 RequestAuthentication 资源中。spec.selector.matchLabels 必须与 PeerAuthentication 上的相同字段配置相类似。spec.origins.jwt 项中特定于 JWT 主体的配置会映射到 spec.rules 项中的类似字段。
-
spec.origins[x].jwt.triggerRules必须映射到一个或多个security.istio.io/v1beta1AuthorizationPolicy 资源。任何spec.selector.labels都必须配置为 RequestAuthentication 上的相同字段。 -
spec.origins[x].jwt.triggerRules.excludedPaths必须映射到一个 AuthorizationPolicy 中，其 spec.action 设置为 ALLOW，带有与排除路径匹配的spec.rules[x].to.operation.path条目。 -
spec.origins[x].jwt.triggerRules.includedPaths必须映射为一个独立的 AuthorizationPolicy，它的spec.action设置为ALLOW，使用与包含的路径匹配的spec.rules[x].to.operation.path条目，以及与 Policy 资源中指定的spec.origins[x].jwt.issuer相对应的spec.rules.[x].from.source.requestPrincipals的条目。
ServiceMeshPolicy (maistra.io/v1)
ServiceMeshPolicy 通过 v1 资源或 spec.security.dataPlane.mtls 中的 spec.istio.global.mtls.enabled 自动为 Service Mesh control plane 配置。对于 v2 control plane，在安装过程中创建了一个功能等同的 PeerAuthentication 资源。此功能在 Red Hat OpenShift Service Mesh 版本 2.0 中已弃用
RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1)
这些资源由 security.istio.io/v1beta1 AuthorizationPolicy 资源替代。
模拟 RbacConfig 行为需要编写默认的 AuthorizationPolicy，其设置取决于 RbacConfig 中指定的 spec.mode。
-
当将
spec.mode设置为OFF时，不需要任何资源，因为默认策略是 ALLOW，除非对请求应用 AuthorizationPolicy。 -
当
spec.mode设为 ON 时，设置spec: {}。您必须为网格中的所有服务创建 AuthorizationPolicy 策略。 -
spec.mode设置为ON_WITH_INCLUSION，必须为每个包含的命名空间中创建一个带有spec: {}的 AuthorizationPolicy。AuthorizationPolicy 不支持包括单独的服务。但是，当创建任何适用于该服务的工作负载的 AuthorizationPolicy 后，未明确允许的所有其他请求都将被拒绝。 -
当
spec.mode设置为ON_WITH_EXCLUSION时，AuthorizationPolicy 不支持它。可创建一个全局 DENY 策略，但必须为每个网格中的每个工作负载创建一个 AuthorizationPolicy，因为没有可用于命名空间或工作负载的 allow-all 策略。
AuthorizationPolicy 包括配置适用的选择器的配置，它类似于 ServiceRoleBinding 提供的函数 ServiceRoleBinding，这与所提供函数 ServiceRole 相似。
ServiceMeshRbacConfig (maistra.io/v1)
此资源由使用 Service Mesh control plane 命名空间中带有空 spec.selector 的 security.istio.io/v1beta1 AuthorizationPolicy 资源替代。该策略是应用于网格中所有工作负载的默认授权策略。如需具体迁移详情，请参阅上面的 RbacConfig。
1.11.4.4.2.5. Mixer 插件
在版本 2.0 中默认禁用 Mixer 组件。如果您的工作负载依赖 Mixer 插件，必须将 2.0 ServiceMeshControlPlane 版本配置为包含 Mixer 组件。
要启用 Mixer 策略组件，在 ServiceMeshControlPlane 中添加以下片断。
spec:
policy:
type: Mixer
要启用 Mixer 遥测组件，在 ServiceMeshControlPlane 中添加以下片断。
spec:
telemetry:
type: Mixer旧版混合程序插件也可以迁移到 WASM，并使用新的 ServiceMeshExtension（maistra.io/v1alpha1）自定义资源进行集成。
Red Hat OpenShift Service Mesh 2.0 不提供上游 Istio 发行本中的内置 WASM 过滤器。
1.11.4.4.2.6. 双向 TLS 的变化
当使用带有特定工作负载 PeerAuthentication 策略的 mTLS 时，如果工作负载策略与命名空间/全局策略不同，则需要一个对应的 DestinationRule 来允许流量。
auto mTLS 默认启用，但可以通过将 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.automtls 设置为 false 来禁用。禁用自动 mTLS 时，可能需要 DestinationRules 进行服务间的正常通信。例如，将一个命名空间的 PeerAuthentication 设置为 STRICT 可能会阻止其他命名空间中的服务访问它们，除非 DestinationRule 为命名空间中的服务配置 TLS 模式。
有关 mTLS 的详情请参考 启用 mutual Transport Layer Security(mTLS)
1.11.4.4.2.6.1. 其他 mTLS 示例
要在 bookinfo 示例应用程序中禁用 mTLS For productpage 服务，您的 Policy 资源需要为 Red Hat OpenShift Service Mesh v1.1 进行以下配置。
策略资源示例
apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: productpage-mTLS-disable namespace: <namespace> spec: targets: - name: productpage
要在 bookinfo 示例应用程序中禁用 mTLS For productpage 服务，请使用以下示例为 Red Hat OpenShift Service Mesh v2.0 配置 PeerAuthentication 资源。
PeerAuthentication 资源示例
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: productpage-mTLS-disable
namespace: <namespace>
spec:
mtls:
mode: DISABLE
selector:
matchLabels:
# this should match the selector for the "productpage" service
app: productpage
为了在 bookinfo 示例应用程序中为 productpage 服务启用 mTLS，您的 Policy 资源被配置为 Red Hat OpenShift Service Mesh v1.1 如下。
策略资源示例
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: productpage-mTLS-with-JWT
namespace: <namespace>
spec:
targets:
- name: productpage
ports:
- number: 9000
peers:
- mtls:
origins:
- jwt:
issuer: "https://securetoken.google.com"
audiences:
- "productpage"
jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
jwtHeaders:
- "x-goog-iap-jwt-assertion"
triggerRules:
- excludedPaths:
- exact: /health_check
principalBinding: USE_ORIGIN
要在 bookinfo 示例应用程序中为 productpage 服务启用 mTLS，使用以下示例为 Red Hat OpenShift Service Mesh v2.0 配置 PeerAuthentication 资源。
PeerAuthentication 资源示例
#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: productpage-mTLS-with-JWT
namespace: <namespace>
spec:
selector:
matchLabels:
# this should match the selector for the "productpage" service
app: productpage
portLevelMtls:
9000:
mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: productpage-mTLS-with-JWT
namespace: <namespace>
spec:
selector:
matchLabels:
# this should match the selector for the "productpage" service
app: productpage
jwtRules:
- issuer: "https://securetoken.google.com"
audiences:
- "productpage"
jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
fromHeaders:
- name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: productpage-mTLS-with-JWT
namespace: <namespace>
spec:
action: ALLOW
selector:
matchLabels:
# this should match the selector for the "productpage" service
app: productpage
rules:
- to: # require JWT token to access all other paths
- operation:
notPaths:
- /health_check
from:
- source:
# if using principalBinding: USE_PEER in the Policy,
# then use principals, e.g.
# principals:
# - “*”
requestPrincipals:
- “*”
- to: # no JWT token required to access health_check
- operation:
paths:
- /health_check
