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
K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址