-
使用ISTIO保护您的微服务
介绍
Istio 是一个开源项目，旨在管理云上微服务之间的通信。它独立于平台，但通常且主要与 Kubernetes 一起使用。Istio 提供了多项关键功能，例如流量管理、安全性和可观察性。 在本文中，我们将重点介绍 Istio 的安全能力，包括增强认证、透明 TLS 加密、身份验证和授权。我们将 Istio 部署在 Kubernetes 集群上，并逐步介绍 Istio 安全功能，讨论这些功能如何保护您的服务。 示例
我们使用 Istio 提供的示例应用 Bookinfo[1] 来演示本文中 Istio 的功能。让我们来看看 Istio 安全和 Bookinfo 的架构。 ISTIO 安全架构
Istio 安全涉及多个组件；下图显示了该架构。在控制平面的 Istiod 组件中，我们有一个 CA（Certificate Authority）来管理证书，相关配置通过 API 服务器发送到数据平面（Envoy）。Envoy 作为策略执行点 (PEP) 来保护网格中客户端和服务器之间或网格外部和内部之间的通信安全。 
Bookinfo应用架构
Bookinfo 应用程序分为四个独立的微服务： · productpage：调用详细信息和评论微服务 · details：包含书籍详细信息 · reviews：调用 ratings 微服务生成书评 · ratings：包含伴随书评的排名信息 评论微服务共有三个版本；productpage 以循环方式访问这些版本： · 版本 v1 不调用ratings服务。 · 版本 v2 调用ratings服务并将每个评级显示为 1 到 5 颗黑星。 · 版本 v3 调用ratings服务并将每个评级显示为 1 到 5 颗红星。 该应用程序的端到端架构如下所示。这些是没有 Istio sidecar 部署的原始纯服务。 
ISTIO 认证
如果您已经安装了 Istio，则无需对应用程序进行任何更改即可运行示例。或者，您可以简单地在支持 Istio 的环境中配置和运行服务，并在每个服务旁边注入 Envoy sidecar。生成的部署如下所示： 
这里我们特意部署了没有 sidecar 的 review-v2 和其他有 sidecar 的服务。这可以通过设置 Kubernetes 命名空间标签“istio-injection=enabled/disabled”轻松控制。一旦我们为 Pod 注入一个 sidecar 或者只是设置一个单一的边缘代理作为入口网关，Istio 身份就会生效。 Istio 身份模型使用一流的服务身份来确定请求来源的身份。在 Kubernetes 上，Istio 使用 Kubernetes 服务帐户作为身份。下图展示了 Istio 的身份配置工作流程。 
-
启动一个注入了 Istio 的 Pod，它还会启动一个 Envoy 实例作为 Pod 的 sidecar。 -
当工作负载启动时，Envoy 通过 Envoy secret发现服务 (SDS) API 从 Istio 代理请求证书。 -
Istio 代理将证书签名请求 (CSR) 及其凭据 (JWT) 发送到 istiod 进行签名。 -
Istio 代理将从 istiod 收到的以 SPIFFE 格式签名的证书通过 Envoy SDS API 发送给 Envoy。
这里的证书是x.509，SPIFFE格式的URL作为x.509证书的扩展字段进行识别。SPIFFE 是开源的；k8s环境下Istio身份的格式类似于“spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>”。我们可以通过使用 Istioctl 工具并手动解析证书中的 Spiffe URL 来获取证书。我们还可以转储并检查 sidecar 的配置以验证 URL 是否已注入其中。 
双向 TLS
Istio 支持双向 TLS 来加密服务之间传输的数据。在 Bookinfo 应用程序中，所有服务最初都是基于纯 HTTP 协议相互通信的，其中数据没有加密。当一个工作负载使用双向 TLS 认证策略向另一个工作负载发送请求时，工作负载和 sidecar 之间的数据仍然是纯文本的，而客户端 Envoy 和服务器端 Envoy 建立双向 TLS 连接。 对等认证
应用对等身份验证策略（如上所示）后，Istio 会自动将两个 PEP 之间的所有流量升级为双向 TLS。由于默认情况下启用了 Istio 的自动 mTLS，因此仍然可以通过 HTTP 访问 Reviews-v2。Istio 中的 Auto-mTLS 有助于确定客户端 Sidecar 可以发送的流量类型： · 如果配置了 DestinationRule，则信任它 · 如果服务器有 sidecar 并允许 mTLS，发送 mTLS – review-v1 & v3 · 否则，发送纯文本 – review-v2 对等身份验证仅定义服务器sidecar可以接收哪种类型的流量。Reviews-v2 没有 sidecar，所以客户端向它发送纯文本。服务器端默认处于 PERMISSIVE 模式，这意味着服务器端可以接受纯文本和 mTLS。这在开始将集群与服务网格集成时非常有用，因为操作员通常无法同时为所有客户端安装 Istio sidecar，或者甚至没有权限在某些客户端上这样做。 
目的规则
与对等身份验证相比，目标规则定义了客户端 Sidecar 可以发送的流量类型。应用目标规则策略（如上所示）后，review-v2 无法再访问，因为目标规则限制 productpage sidecar 发送 mTLS 流量，而 review-v2 只能接收纯文本。 
保护入口流量
Istio 支持通过入口网关将安全的 HTTPS 服务暴露给外部流量，因此无需更改内部协议。它总共支持四种模式来在入口启用 TLS。SIMPLE/MUTUAL 和 ISTIO_MUTUAL 对传入的请求执行 TLS 终止；它们用于配置对 HTTP 服务的 
HTTPS 入口访问。PASSTHROUGH 和 AUTO_PASSTHROUGH 仅按原样传递入口流量，而不是使用 TLS 终止。 授权入口流量
添加要求最终用户 JWT 用于入口网关的请求身份验证策略。如果您在授权标头中提供令牌（其隐式默认位置），则 Istio 将使用公钥集验证令牌，并在不记名令牌无效时拒绝请求。但是，接受没有令牌的请求。 
要拒绝没有有效令牌的请求，请添加一个 AuthorizationPolicy 规则，为具有请求主体的请求指定 ALLOW 操作，在上面的示例中显示为 requestPrincipals。requestPrincipals 仅在提供有效的 JWT 令牌时可用。因此，该规则只允许具有有效令牌的请求。 
应用RequestAuthentication，如上图： · 使用有效的 JWT 令牌请求 √ · 请求没有 JWT 令牌 √ · 使用无效的 JWT 令牌请求 × 应用AuthorizationPolicy，如上图 · 使用有效的 JWT 令牌请求 √ · 没有 JWT 令牌的请求 × · 使用无效的 JWT 令牌请求 × 网格流量中的授权
AuthorizationPolicy 不仅可以应用于入口网关，还可以用于控制网格内部的访问。授权策略规范包括选择器、操作和规则列表： · 选择器字段指定策略的目标 · action 字段指定是允许还是拒绝请求；默认值为“允许” · 规则指定何时触发动作 o 规则中的 from 字段指定请求的来源 o 规则中的 to 字段指定请求的操作 o when 字段指定应用规则所需的条件 如果应用拒绝所有 AuthorizationPolicy，则默认命名空间下的服务之间的所有请求都将被拒绝。如果您随后应用 productpage-viewer 如下例所示，它允许对 productpage 服务进行“GET”操作。 
与productpage-viewer AuthorizationPolicy相比，reviews-viewer在spec规则的source字段多了一项配置；它指定只允许具有“[“cluster.local/ns/default/sa/bookinfo-productpage”]”服务帐户的服务发送“GET”请求。一一应用其他 AuthorizationPolicy 并测试产品页面。Bookinfo 服务提供的不同信息都会再次出现在您的网页上。 概括：Istio 自动提供强大的识别功能。它还具有双向 TLS，可对流量进行加密以抵御中间人攻击。Auto-mTLS 帮助您加入 Istio，PeerAuthentication 和 DestinationRule 简化了对配置进行细微调整的过程。此外，Istio 提供了灵活的服务访问控制，因此您可以使用 RequestAuthentication、AuthorizationPolicy 等来设置细粒度的访问策略。
参考
· Istio 官方文档：https ://istio.io/latest/docs/ · https://istio.io/latest/docs/examples/bookinfo/ 原文
https://01.org/blogs/luyaozhong/2021/secure-your-microservices-istio -
云和安全管理服务专家
