本文转载自微信公众号《新钛云服务》，作者朱翔。转载本文请联系新钛云服务公众号。Istio是一个开源项目，旨在管理云上微服务之间的通信。它独立于平台，但通常且主要与Kubernetes一起使用。Istio提供了几个关键特性，例如流量管理、安全性和可观察性。在本文中，我们将重点介绍Istio的安全功能，包括增强的身份验证、透明的TLS加密、身份验证和授权。我们在Kubernetes集群上部署Istio并介绍Istio安全功能，讨论它们如何保护您的服务。示例我们使用Istio提供的示例应用程序Bookinfo[1]来演示Istio在本文中的功能。让我们看一下Istio安全性和Bookinfo架构。ISTIO安全架构Istio安全涉及多个组件；下图显示了架构。在控制面的Istiod组件中，我们有一个CA（CertificateAuthority）来管理证书，相关配置通过APIserver发送给数据面（Envoy）。Envoy充当策略执行点(PEP)，以保护网格中客户端和服务器之间或网格外部和内部之间的通信。Bookinfo应用架构Bookinfo应用分为四个独立的微服务：productpage：调用详情和评论微服务details：包含书籍详情eviews：调用评分微服务生成书评ratings：包含书评附带的排名信息三个版本；productpage以循环方式访问这些版本：·Versionv1不调用ratings服务。·版本v2调用评级服务并将每个评级显示为1到5颗黑星。·版本v3调用评级服务并将每个评级显示为1到5颗红星。应用程序的端到端架构如下所示。这些是在没有Istiosidecar的情况下部署的原始纯服务。ISTIO认证如果您已经安装了Istio，则无需对应用程序进行任何更改即可运行示例。或者，您可以简单地在支持Istio的环境中配置和运行服务，并在每个服务旁边注入一个Envoysidecar。生成的部署看起来像这样：这里我们有意部署没有sidecars的review-v2和其他有sidecars的服务。这可以通过设置Kubernetes命名空间标签“istio-injection=enabled/disabled”来轻松控制。一旦我们将sidecar注入pod或简单地将单个边缘代理设置为入口网关，Istio身份就会发挥作用。Istio身份模型使用一流的服务身份来确定请求源的身份。在Kubernetes上，Istio使用Kubernetes服务帐户作为身份。下图显示了Istio身份配置工作流程。启动一个注入了Istio的Pod，它还会启动一个Envoy实例作为Pod的sidecar。当工作负载启动时，Envoy通过EnvoySecretDiscoveryService(SDS)API从Istio代理请求证书。Istio代理将证书签名请求(CSR)及其凭据(JWT)发送到istiod进行签名。Istio代理通过EnvoySDSAPI将从istiod接收的以SPIFFE格式签名的证书发送给Envoy。这里的证书是x.509，SPIFFE格式的URL被识别为x.509证书的扩展域。SPIFFE是开源的；k8s环境下Istioidentity的格式类似于“spiffe:///ns//sa/”。我们可以使用Istioctl工具，手动解析证书中的SpiffeURL获取证书。我们还可以转储并检查sidecar的配置，以验证URL是否已注入其中。MutualTLSIstio支持MutualTLS来加密服务之间传输的数据。在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对等身份验证仅定义服务器边车可以接收的流量类型。Reviews-v2没有sidecar，所以客户端向它发送纯文本。服务器端默认是PERMISSIVE模式，也就是说服务器端可以接受明文和mTLS。这在开始将集群与服务网格集成时非常有用，因为运维人员通常无法同时为所有客户端安装Istiosidecar，或者甚至没有在某些客户端上安装Istiosidecar的权限。目标规则与对等身份验证相反，目标规则定义了客户端可以发送的流量类型。应用目标规则策略（如上所示）后，review-v2不再可访问，因为目标规则限制了productpagesidecar发送mTLS流量，而review-v2只能接收纯文本。保护入口流量Istio支持通过入口网关将安全的HTTPS服务暴露给外部流量，因此不需要更改内部协议。它总共支持四种模式来启用TLSoningress。SIMPLE/MUTUAL和ISTIO_MUTUAL对传入请求执行TLS终止；它们用于配置对HTTP服务的HTTPS入口访问。PASSTHROUGH和AUTO_PASSTHROUGH只是按原样传递入口流量，而不是使用TLS终止。授权入口流量添加请求身份验证策略，该策略需要入口网关的最终用户JWT。如果您在授权标头（其隐含的默认位置）中提供令牌，Istio将使用公钥集验证令牌并在不记名令牌无效时拒绝请求。但是，接受没有令牌的请求。要拒绝没有有效令牌的请求，请添加AuthorizationPolicy规则，为具有请求正文的请求指定ALLOW操作，如上例中的requestPrincipals所示。requestPrincipals仅在提供有效的JWT令牌时可用。因此，该规则只允许具有有效令牌的请求。应用RequestAuthentication，如上图：RequestwithavalidJWTtoken√RequestwithoutaJWTtoken√RequestwithainvalidJWTtoken×ApplyAuthorizationPolicy，如上图RequestwithavalidJWTtoken√RequestwithoutaJWTtoken×UseinvalidJWTTokenRequest×GridTrafficAuthorizationAuthorizationPolicy不仅可以应用于ingressgateway，还可以用来控制网格内部的访问。授权策略规范包括选择器、操作和规则的列表：选择器字段指定策略的目标操作字段指定是允许还是拒绝请求；默认值为“允许”规则指定何时触发操作规则中的from字段指定请求source规则中的to字段指定请求的操作，when字段指定应用规则所需的条件。如果应用程序拒绝所有AuthorizationPolicies，则默认命名空间下的服务之间的所有请求都将被拒绝。如果您随后像下面的示例一样应用productpage-viewer，它允许对productpage服务执行“GET”操作。与productpage-viewerAuthorizationPolicy相比，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-你的微服务-istio
