Istio Service Mesh | Kserve文档

type

status

date

slug

summary

启用严格mTLS和授权策略

为实现命名空间流量隔离，我们将集群内流量限制为仅允许来自同一命名空间的请求，并启用mTLS以进行TLS加密和基于强身份的认证。由于Knative请求经常通过activator路由，在启用mTLS时需要额外的流量规则，并且knative-serving命名空间中的activator/autoscaler必须注入sidecar。有关更多详细信息，请参阅Knative中的mTLS，要了解请求何时通过activator转发，请参阅目标突发容量文档。

创建本示例将使用的命名空间user1。

当激活器不在请求路径上时，规则会检查请求的源命名空间是否与InferenceService的目标命名空间相同。

当激活器在请求路径上时，规则会检查源命名空间knative-serving，因为请求是通过激活器代理的。

警告:目前当激活器在请求路径上时，由于net-istio问题，无法检查请求的原始命名空间或原始身份。

使用 PeerAuthentication 和 AuthorizationPolicy 规则应用 auth.yaml：

禁用顶层虚拟服务

KServe目前创建一个Istio顶层虚拟服务，用于支持InferenceService组件（如预测器、转换器和解释器）之间的路由，以及支持基于路径的路由作为服务主机的替代路由方式。在无服务器服务网格模式下，这会产生一个问题：为了通过Knative Service创建的底层虚拟服务进行路由，顶层虚拟服务需要路由到Istio Gateway，而不是直接路由到服务网格上的InferenceService组件。

通过禁用顶层虚拟服务，可以消除到Istio本地网关的额外路由，当服务之间直接建立mTLS连接且activator不在请求路径上时，授权策略可以检查源命名空间。要禁用顶层虚拟服务，请在inferenceservice配置映射的ingress配置下添加标志"disableIstioVirtualHost": true。

在整个服务网格上启用严格的mTLS

在前一节中，我们讨论了如何在命名空间级别启用严格的mTLS。对于需要锁定服务网格中所有工作负载的用户，可以为整个网格配置严格的mTLS。

Istio的Mutual TLS迁移文档使用PeerAuthentication资源来锁定网格，这些资源在服务器端起作用。这意味着Istio边车只会拒绝非mTLS传入连接，而非TLS的出站连接仍将被允许（参考）。要进一步锁定网格，您还可以创建DestinationRule资源来要求出站连接使用mTLS。但是，在这种非常严格的mTLS配置下，您可能会注意到KServe顶层虚拟服务将停止工作，推理请求将被阻止。您可以通过如上所述禁用顶层虚拟服务来解决这个问题，或者通过在Knative的本地网关的监听端口上配置mTLS来解决。

要在Knative的本地网关上配置mTLS，假设您已按照Knative使用Istio作为网络层的指南进行操作，您需要将knative-local-gateway资源修补为如下所示：

修补完Knative的本地网关资源后，KServe的顶层虚拟服务将重新开始工作。

使用Istio边车注入部署推理服务

首先用istio-injection=enabled标记命名空间，以启用该命名空间的边车注入。

创建带有和不带有 Knative activator 请求路径的推理服务：当 autoscaling.knative.dev/targetBurstCapacity 设置为 0 时，Knative 会从请求路径中移除 activator，这样测试服务就可以直接与 InferenceService 建立 mTLS 连接，同时授权策略可以检查请求的原始命名空间，从而实现命名空间流量隔离。

带有 activator 请求路径的推理服务和不带有 activator 请求路径的推理服务

预期输出

在相同命名空间中运行预测

在 user1 命名空间中使用 httpbin.yaml 部署测试服务。

向没有激活器的 sklearn-iris 推理服务发送预测请求，由于授权规则允许来自同一命名空间的流量，预期会收到 HTTP 200 响应。

预期输出

向带有激活器的 sklearn-iris-burst 推理服务发送预测请求，由于授权规则允许来自 knative-serving 命名空间的流量，预期会收到 HTTP 200 响应。

预期输出

从不同的命名空间运行预测

在default命名空间中使用sleep.yaml部署测试服务，该命名空间与部署InferenceService的命名空间不同。

当您从不同命名空间向没有activator的sklearn-iris InferenceService发送预测请求时，由于授权规则仅允许来自部署InferenceService的同一命名空间user1的流量，预期会收到HTTP 403 "RBAC denied"错误。

预期输出

当您从不同命名空间向带有activator的sklearn-iris-burst InferenceService发送预测请求时，由于上述限制，实际上会收到HTTP 200响应，这是因为授权策略无法将流量仅限制在同一命名空间内，原因是请求是通过knative-serving命名空间中的activator代理的。一旦上游Knative的net-istio修复后，我们预期会收到HTTP 403响应。

预期输出

从非网格工作负载调用推理服务

理想情况下，使用服务网格时，所有相关工作负载都应属于服务网格。这样可以在Istio中启用严格的mTLS，并确保策略得到正确应用。但是，考虑到应用程序的多样化需求，并不总是能够将所有工作负载迁移到服务网格中。

在使用KServe时，您可以成功地将推理服务迁移到服务网格（即通过注入Istio sidecar），而调用推理的工作负载仍在网格之外。在这种混合环境中，不属于服务网格的工作负载需要使用Istio入口网关作为进入推理服务的入口点。在默认设置中，KServe与Knative使用的网关集成。Knative和KServe都应用了必要的配置以支持这些混合环境，但这种透明工作方式仅适用于未在Istio上启用严格TLS的情况。

特别是在网格范围内高度严格的mTLS设置下（涉及PeerAuthentication和DestinationRule资源，如上文所述），您会发现不属于网格的工作负载将无法调用推理服务。解决这个问题最简单的方法是禁用KServe顶层虚拟服务。但是，如果您需要KServe顶层虚拟服务，您仍然可以通过为KServe配置专用的本地Istio网关来实现一个可用的混合环境。

首先，您需要修补Knative网关，如上文所述用于开启网格范围的严格mTLS。然后，您需要创建以下资源：

最后，您需要编辑推理服务ConfigMap中的ingress配置，使其包含以下内容：

重启 KServe 控制器后，所需的服务和虚拟服务将被重新配置，网格外的工作负载将可以调用推理服务。

使用 TLS 保护网络边界

如果您需要在整个网络上使用 TLS，最简单的方法是在 Istio 中启用网格范围的严格 mTLS。但是，通信仅对服务网格内的工作负载是安全的，而网格边界是薄弱环节：如果 Istio 入口网关未配置 TLS，到达或离开网格的数据仍然是明文。

如果您需要在网格边界处为入站连接启用 TLS 安全：

对于来自集群外部的请求（即公共端点），您可以参照 Knative 外部域加密指南

对于来自集群内部但不属于服务网格的工作负载的请求，您可以使用 Knative 集群本地加密，尽管它仍处于实验状态。这还需要您禁用 KServe 顶层虚拟服务以确保没有明文入口点。

如果实验性的 Knative 集群本地加密不适合您，仍然可以通过为 KServe 配置专用本地网关来保护网格边界的集群本地流量，方法如前所示。需要创建以下资源：

在 istio-system 命名空间中，您需要创建一个名为 kserve-cluster-local-tls 的Secret来存储TLS证书。您可以从 cert-manager 操作符获取此证书。

最后，在inferenceservice ConfigMap中编辑 ingress 配置，使其包含以下内容：

重启 KServe 控制器后，网格外的集群本地工作负载需要使用 HTTPS 来运行预测。

如果您将 TLS 边界保护和基于 Istio 的网格范围严格 mTLS 配置结合使用，最终将实现一个对带有 sidecar 的 KServe 工作负载的流量进行全面安全保护的设置。