Istio安全基础：在零可信网络上运行微服务

Posted 2021-04-13 分布式实验室

在 ，我们概述了Istio的特性和功能，以及用户为什么希望在Kubernetes集群中用或不用它作为服务网格。在本篇文章中，我们将稍微深入地探讨服务网格中，Istio如何帮助改进应用程序的运行时的安全性，以及它在Kubernetes安全控制和实践的全局中处于什么位置。

完全不可信

Istio提供了大量的功能，来支持在零信任网络上安全地运行微服务的能力。

零信任模型是建立在网络和基础设施可能被恶意代码、错误配置或其他不利因素所渗透的可能性之上。这个模型仅仅是假定在用户的Kubernetes集群上，可以运行任何指定的微服务。需要说明的是：这个假定不表示所指定的微服务是合理的，或可以毫无疑问地被信任的。在一组相互调用的分布式微服务中，新服务随时可以出现，并且不需要修改配置的情况下，被其他服务使用或调用。这自然就衍生出Kubernetes集群中应用安全管理的一个关键组件，既与其他应用CI/CD和基础设施最佳实践相结合的，凭证识别和验证的零信任哲学。

在支持零信任网络的部分，Istio提供了附加的4-7层防火墙控制、传输加密、服务网格的高级服务和终端用户身份验证和授权的可选项，以及捕获详细连接日志和指标的能力。与Istio的大多数其他功能一样，这些功能都是由Envoy代理提供支持的。Envoy代理以sidecar（边车）容器的方式运行在每个应用程序的Kubernetes Pod中。

mTLS：信任与校验

mTLS（相互传输层安全性）是Istio安全工具集的一个基本部分。它不仅提供传输加密，还在服务网格中，提供服务对服务的身份验证和授权。

工作原理：网格中的每个服务都有自己的TLS证书，由Istio Citadel服务颁发和管理。在一个给定的网络连接中，客户端服务的Envoy代理将向服务端提供其证书，同时验证服务器的TLS证书的有效性。目标服务的Envoy代理将验证客户端证书，而且还可以通过客户端身份来判断该服务是否允许被连接。后者是基于Istio服务的RBAC（基于角色的访问控制）配置和策略配置来实现的。TLS加密的功能还表示即使应用本身不支持TLS加密，也不会通过网络发送明文的数据包。

Istio RBAC授权非常类似于Kubernetes原生RBAC的扩展。在服务网格中，ServiceRole可以在创建服务的端点权限的时候定义。它们可以绑定经过身份验证的实体，如Kubernetes服务帐户、使用JWT令牌验证身份的外部用户（具备服务访问权限）等。Istio RBAC的评估是在代理的sidecar容器中执行，因此处理延迟非常低。不过，对于大多数应用而言，上述所有的操作都是完全透明的，不需要对部署进行任何配置更改。

实现需求：默认情况下，未启用全局mTLS。用户可以在Istio安装时设置它。配置参数为：lobal.mtls.enabled=true，或安装后在每个命名空间或全局配置中打开它。操作方法链接参见：https://istio.io/docs/concepts/security/#enabling-authorization。

潜在问题：对于用于使用自己的客户端证书进行身份验证（内置HTTPS）而没有HTTP选项的应用，将无法适用Istio的mTLS功能，因为mTLS不支持隧道TCP，应用需要采用额外的Istio配置来绕过mTLS功能。

在只有一个服务子集或命名空开启了mTLS功能的集群中，在可行的情况下，必须使用Kubernetes网络策略隔离集群中不属于服务网格的资源。

策略检查：细粒度的身份验证和授权控制

Mixer是Istio的策略控制服务，在Istio服务网格中，它能够提供多种方式对应用添加访问控制。它不仅提供了许多开箱即用的适配器，它的可插拔适配器模型还允许用户在需要时部署和使用自己的验证机制。

虽然我们已经了解服务网格中，使用mTLS强制力和Istio RBAC处理服务到服务的身份验证和授权，但是来自集群外的传入连接通常不会提供有效的mTLS证书。Mixer支持JSON Web令牌（JWT）的授权方式，可以对最终用户或外部的上游服务进行身份验证。或者用户也可以通过一个自定义的Mixer适配器创建策略检查，来提供身份验证方法。

连接请求一旦经过身份验证，策略检查就将提供无数的选项来决定是否允许请求访问。根据请求的协议类型，Istio为策略检查提供大量的连接属性，其中非TLS HTTP服务的属性选项最为丰富，包括URI路径、请求头内容、查询参数和其他属性等。甚至还可以使用Istio RBAC授权，不过由于RBAC评估是基于静态规则，所以对于源自服务网格之外的连接，大概率上会不太有用。

工作原理：当为服务网格启用策略检查时，目标Envoy代理连接到Mixer策略服务，确认每个传入连接的请求是否被允许或拒绝。Mixer判断对服务应用哪些策略，并计算传入请求连接的各种属性。

实现需求：缺省情况下不启用Mixer检查的强制策略。可以在安装时使用global.disablePolicyChecks=false配置开启，也可以在安全完成后再开启。

潜在问题：因为目标Envoy代理必须连接到Istio的Mixer策略服务，以确认每个请求的授权，启用策略检查会给连接增加一些时延。当自定义或第三方适配器与Mixer一起使用时，必须确保代码质量、可靠性和部署模式，以防止后端服务不可用时，出现延迟和宕机，同时，还需确保身份验证和授权结果是正确的。

出口流量控制

Kubernetes通过标准化部署配置，减少基础设施资源分配的摩擦，来显著帮助开发人员加快现有应用迭代部署和新应用发布的速度。但这种加速并没有降低应用程序行为的监视需求，其中网络出口就是一个重要部分。基于审计，数据安全、恶意程序侵入容器后的损害控制等目的，了解和控制所访问第三方服务就变得非常重要。

默认情况下，Istio阻断了到发往服务网格外端点的所有流量，除非将外面服务显式地记录在白名单中。

工作原理：如果网格的出站服务策略设置为REGISTRY_ONLY，那当应用的Envoy代理检测到所连接的目标服务为服务网格以外的服务时，它将检查目标服务是否有ServiceEntry配置，如果配置存在，完成建立连接；如果配置不存在，则根据协议向源应用返回一个错误或断开连接。

通过部署Istio出口网关，并通过网关路由出口流量，可以进一步控制和监视出口流量。当与Kubernetes网络策略相结合时，这些策略不仅允许Istio的出站网关建立到集群外的连接，还可以帮助防止Kubernetes集群中的任何异常容器或进程绕过Envoy代理，自行建立外部连接。

实现需求：默认情况下，出口流量是不受限制的开放的。可以在安装时用这个配置：global.outboundTrafficPolicy.mode=REGISTRY_ONLY关闭，或后面在配置中开启。

潜在问题：从开放的出站策略管理思维转向只针对白名单的策略可能会有点困难，因为有许多内部和第三方应用程序都依赖SaaS服务，即使用户认为自己知道容器正在访问哪些外部站点，也会出现部分HTTP请求被重定向，发生出口连接失败的现象。失败后，HTTP 301 / 302重定向会返回给客户端，然后由客户端重新建立到新位置的连接。除此之外，一个HTTP GET可以很轻易就变成多个重定向层，每个重定向层都需要加到白名单。

 
   
   
 

  
    
    
  
$ curl -sL -D - -o /dev/null http://www.docker.io/ HTTP/1.1 301 Moved Permanently Content-length: 0 Location: https://www.docker.io/
  
    
    
  
HTTP/1.1 301 Moved Permanently 
  
    
    
  
Content-length: 0 Location: https://www.docker.com/
  
    
    
  
HTTP/2 200 content-type: text/html; charset=UTF-8 content-length: 86100
  
    
    
  
[…]
 
   
   
 

受限于Istio版本、协议和集群配置差异，Istio无法一致地记录失败的出口连接，导致确定出站连接的准确目标可能会比较困难。

默认情况下，强制所有出口流量通过出口网关是不现实的。Istio没有提供全局网关的配置，而且将流量引导到出口网关的VirtualService资源对目标地址的通配符处理也有限，这主要是由于Envoy代理中的限制所导致的。

是瑞士军刀，而非工具箱

虽然Istio为应用网络安全提供了一系列的控制措施，但它并不是一个全面的解决方案。它的推荐用法是与低层基础设施的网络控制和Kubernetes的常规安全最佳实践相结合使用。值得注意的一个重要的缺陷就是Istio不支持TCP之外的任何协议，因为Envoy代理目前只支持4层TCP协议。这也意味着，如果用户需要监视或控制服务网格中的UDP或SCTP流量，用户需要使用Kubernetes的网络策略实现。如果用户的Kubernetes服务提供者不支持网络策略，用户将必须查看他们是否提供其他网络控制方案。网络策略的可用和可配置，对Istio的控件是很好的补充和增强。同时，用户必须保护集群中Istio资源的安全性，以确保Istio的保护功能不会被错误地、恶意地覆盖或禁用。

由于Istio完全使用Kubernetes标准的资源定义（ConfigMaps和Secrets），以及Istio自己的Kubernetes自定义资源定义（CRDs）。任何具有集群级别RBAC管理特权的个人或服务帐户都可以修改定义配置，而且Istio使用Kubernetes命名空间对工作负载进行逻辑分组，所以，用户必须确保使用最小特权原则限制RBAC授权，并按照推荐的最佳安全实践进行部署和加强。

后续的Istio博客系列，将进一步深入介绍，并提供如何设置和利用Istio安全特性的示例。

原文链接：https://www.stackrox.com/post/2019/08/istio-security-basics-running-microservices-on-zero-trust-networks/

Kubernetes入门与实战培训

Kubernetes入门与实战培训将于2019年11月22日在北京开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，点击下方图片或者阅读原文链接查看详情。