Service Mesh安全：当入侵者突破边界，如何抵御攻击？| CNBPS 2020演讲实录

大家好，我是来自灵雀云的邢海涛，今天演讲的主题是Service Mesh安全，主要从四个方面来跟大家做一下分享。首先介绍Service Mesh 安全需求，然后详细介绍Istio的安全实现，随后介绍两款Service Mesh产品的安全特性：LinkerD 和 Alauda Service Mesh。希望通过这个演讲，让大家了解Istio的无代码侵入，灵活的安全解决方案，启发大家思考自己的安全解决方案，以及如何迁移到Istio的安全模型。

01 Service Mesh安全需求

安全无处不在。为了适应企业数字业务的快速发展，企业应用架构正在从单体架构过渡到微服务架构。一方面，微服务架构带来更好的敏捷性，可伸缩性和更好的重用服务能力。另一方面，架构师不得不面对汹涌的网络攻击。

同时，结合无处不在的互联网访问，设备扩展和云计算，企业应用还要面对更多防火墙内部和外部的基础设施、系统和用户数量。企业应用不得不面对零信任网络环境。

我们认为，Service Mesh安全需求可以分为上面三类：网络攻击、服务访问控制和审计。防御网络中间人攻击，流量加密是必须的。为了提供对应用和用户的访问控制，Service Mesh需要双向TLS和细粒度的访问策略。为了确定谁在什么时候做了什么，需要审计工具。

02 全方位Istio安全

这张图来自Istio官网。Istio安全性的目标是：
默认情况下的安全性：无需更改应用程序的代码和基础架构
深度防御：与现有安全系统集成以提供多层防御
零信任网络：在不受信任的网络上构建安全解决方案

说到底，Istio安全主要有两项功能：即无代码侵入前提下，实现流量加密和AAA（验证、授权、审计）。流量加密，用来解决零信任网络的问题。Istio的AAA是在集成现有安全协议/标准之上实现的，这些安全协议/标准包括双向TLS，JWT，OpenID Connect等。

其他描述都是支撑这两大功能：秘钥和证书管理都是为支撑流量加密的基础设施；identity用来支撑身份验证机制；policy用来支撑授权机制；endpoints，communication，data都是加密的对象。

这张图显示了Istio安全体系架构，构建于Istio控制平面和数据平面的基础架构之上。控制平面主要实现如下功能：
Citadel组件作为证书颁发机构（CA），用于密钥和证书管理
接受来自API server下发的配置信息：认证策略、授权策略、安全的命名信息
Pilot组件负责下发配置信息给Sidecar proxy。

数据平面在安全方面则提供两大功能：
Sidecar和外围代理充当策略执行点 （PEP），以保证客户端和服务器之间的通信。
一组Envoy代理扩展，用于管理遥测和审计

总之，控制平面处理来自API server的配置信息，并下发到数据平面，数据平面sidecar Envoy充当策略执行点执行安全策略。

双向TLS就是Service Mesh安全的基础，流量加密和AAA都是基于双向TLS实现的。双向TLS包含一个握手的过程，用于相互检查验证对方身份，这里都是可选操作，可以选择单向验证，甚至不验证。然后是交换对称秘钥，最后用对称秘钥加密通讯内容。

这里验证身份的过程就是利用证书来完成的，证书就是一个passport，由证书权威机构签发的，有时效性的包含你是谁的一段信息。这里签发就是用证书权威机构的私钥给这段信息的摘要签名的过程。

验证过程就是检查证书权威机构是否被信任，证书是否过期，以及检查证书持有者的IP，域名或服务名和证书是否一致。

Istio的安全模型都是围绕双向TLS实现的：
自建证书权威机构，让私钥和证书轮换自动化
强制双向的身份认证
客户端检查服务端身份的同时，还要检查谁在运行服务端，这个人是否有资格运行服务端
服务端检查客户端身份的同时，启动授权机制，检查客户端是否有权访问服务端的资源

Istio提供了一个相当灵活的身份模型。Istio使用service identity作为身份，可以表示人类用户，单个workload或一组workload。支持多种公有云平台，在没有服务身份的平台上，Istio可以使用服务名称作为Workload实例的身份。

Istio使用X.509证书为每个Workload设置强身份。Envoy代理、Istio agent和istiod协同一起工作，实现了密钥产生和证书轮换的自动化。

这个过程是这样的：Envoy通过Envoy 定义的API向Istio agent发送证书和密钥请求。Istio agent收到请求后，会先创建私钥和CSR证书签名请求,然后将请求及凭据发送到istiod。Istiod的CA验证CSR中携带的凭据，并对CSR签名以生成证书，并返回给istio agent。Istio agent 将收到的证书和私钥发送给Envoy。通过定期反复的上述过程，istio实现了密钥产生和证书轮换的自动化。

Istio身份验证包含两种类型：对等身份验证和请求身份验证。对等身份验证用于service to service的身份验证，请求身份验证用于对用户和人的身份验证。

对等身份验证用于service to service 的身份验证，以验证建立连接的客户端。Istio将来自客户端的出站流量重新路由到客户端的本地Sidecar Envoy。客户端Envoy与服务器端Envoy开始相互TLS握手。通常的TLS握手，会验证证书的签名，检查证书是否过期，以及证书里名称和域名一致。但Istio Envoy之间在握手，客户端Envoy还会进行安全的命名检查，而不是检查域名和证书是否一致，以验证服务器证书中提供的服务帐户service account是否有权运行目标服务。

客户端是通过服务发现或DNS检索证书中的服务名称的，能够防止HTTPS流量受到一般网络劫持。但是，不能防止DNS欺骗。这也说明Istio还要依赖于底层基础设施的安全保障。客户端Envoy和服务器端Envoy建立了相互TLS连接，Istio将流量从客户端Envoy转发到服务器端Envoy。授权后，服务器端Envoy通过本地TCP连接将流量转发到服务端的服务。

Istio通过使用JSON Web令牌（JWT）验证进行请求身份验证，便于集成使用OpenID Connect的应用。我们使用YAML文件来定义验证策略。部署后，策略将保存在Istio配置存储中。Istio控制器监控配置存储。在任何策略更改后，新策略都会转换为适当的配置，通知Envoy sidecar如何执行这些策略。验证策略可以包含用于验证JWT的公钥，以便传递给envoy sidecar。

Istio授权支持service to service的授权，以及针对最终用户和人的授权访问。Istio授权提供了一个CRD形式的灵活简单的API，我们可以自定义条件，使用DENY和ALLOW动作作为结果。

本地Envoy上执行的授权过程，保证了高性能。同时为了减轻运维人员的负担，Istio支持不同级别分级的授权机制，即从网关，到命名空间再到具体的workload的控制级别。

我们也能看到Istio授权机制的演进过程，从1.4版开始，支持基于策略的授权机制及PBAC，而之前提供的是RBAC的机制，通过左右对比，可以看到由两个CRD化简到一个CRD完成，语义功能上没有丝毫的减弱。

Istio 安全的审计功能比较简单。因为envoy的access log可以输出到标准输出，并可由kubectl logs访问。通常由PaaS平台统一收集处理，可以考虑增加过滤条件进一步便捷审计查询。

03 Linkerd安全

Linkerd是第一代service mesh，目前已经发展到第二代，由于第一代Linkerd十分笨重，第二代设计上放弃了可选实现的多样性选择。因此，第二代Linkerd非常轻量，性能非常高。Linkerd官网展示的4个案例，都是始于Istio，最终选择linkerd实施service mesh的。

默认情况下，Linkerd自动给mesh里的通讯加上双向TLS，但是对流入和流出的流量不强制加密。另外，LinkerD使用的kubenetes Service Account token目前是共享的，依赖kubernetes版本更新，将得以修复。

04 Alauda Service Mesh安全

Alauda Service Mesh是灵雀云推出的Service Mesh产品，基于原生Istio，运行在Kubernetes之上，提供了一键部署、可视化管理、可视化配置、便捷的灰度发布等功能，极大降低运维难度，降低了学习Service Mesh的成本。

Alauda service mesh目前支持针对工作负载workload级别的手动配置双向TLS，设置双向TLS的严格模式和兼容模式。

END
​