Istio的安全机制防护

一、Istio安全简介

Istio于北京时间7月31日晚24点发布1.0版本，首次可用于生产环境。目前Istio的安全机制主要包括基于RBAC的访问控制、认证策略、双向TLS认证、服务健康检查等几个方面[1]，Istio 提供了安全操作指南以便于验证其安全机制，感兴趣的同学可以通过访问官方网站学习。

众所周知，将传统的单体应用拆分为一个个微服务固然带来了各种好处，包括更好的灵活性、可伸缩性，重用性，但微服务也同样面临着特殊的安全需求，如下所示：

（1） 为了抵制中间人攻击，需要对流量进行加密。

（2） 为了提供灵活的服务访问控制，服务间需要相互TLS和更细粒度的访问策略。

（3） 为了审核谁在什么时候做了什么，需要安全审计工具。

面对这些需求Istio尝试提供全面的安全解决方案，目前已提供了身份验证策略，透明的TLS加密以及授权和审计工具。借助这些安全机制，Istio推动如下安全目标：

（1） 默认的安全性：无需修改即可保证应用程序代码和架构的安全性。

（2） 纵深防御：与现有的安全系统结合并提供多层防御。

（3） 零信任网络：在不受信任的网络上构建安全解决方案。

需要说明的是，传统基础设施层实现纵深防御和零信任网络是通过网络层面的层层隔离和访问控制实现的，而微服务架构是工作在平台层，所以是通过应用层的认证授权的策略实现的。

Istio的安全防护机制如图1所示：

图1 Istio的安全机制

目前Istio已提供了一套高级别的安全架构，其安全性涉及Istio的多个重要组件：

（1）Citadel：用于管理密钥和证书

（2）sidecar和perimeter proxies：实现客户端和服务端之间的安全通信。

（3）Pilot：将身份验证策略和安全命名信息分派给代理。

（4）Mixer：用于管理授权和审计。

Istio的安全架构如图2所示：

图2 Istio的安全架构

Istio的安全解决方案主要通过在微服务所属容器旁部署一个Sidecar容器来对服务的安全进行防护。主要分为以下三个方面：

二、认证策略

Istio的认证策略主要由两部分组成，分别为Peer策略（TLS相互认证）和Origin策略（验证发出请求源）。执行过程通常是使用Kubernetes中的自定义资源定义（CustomResourceDefinitions，CRD）去定义策略相关配置，然后由Istio的Pilot组件分发到Sidecar容器中去执行。认证策略架构如图3所示:

图3 Istio认证策略架构

三、服务间TLS身份验证

Istio使用TLS为每个微服务提供强大的身份验证机制，并通过角色管理来实现跨集群和云的功能。此外，TLS认证机制还确保了服务与服务之间的通信安全。

Istio官方给出的身份认证架构如图4所示，主要分为身份、密钥管理和通信安全三个组件。此图描述了服务frontend以服务账户frontend-team运行，服务backend以服务账户backend-team运行。它们的通讯原来是没有进行加密的，但Istio在不修改代码的前提下，依托Envoy形成的服务网格，直接在客户端Envoy和服务端Envoy之间进行通讯加密。

图4 Istio TLS身份认证架构图

四、基于RBAC的访问控制

Istio为Service Mesh中的微服务提供基于角色的访问控制（Role-Based Access Control，RBAC）。Istio提供了基于角色的语法让用户填写yaml文件，部署后Istio将策略保存至Istio Config存储中。Pilot监控着Istio访问控制策略的变更，若有更改，将获取更新后的访问控制策略，同时将策略分发到Envoy代理中，每个Envoy代理都运行一个授权引擎，当请求到达Envoy代理时，授权引擎根据策略评估当前请求的上下文，并返回授权结果，ALLOW或DENY。访问控制过程如图5所示：

图5基于RBAC的访问控制架构图

五、总结

以上为Istio的安全机制简介，Istio的出现不但解决了第一代微服务的痛点，在安全性上也是非常有保障的。

[1] https://istio.io/docs/tasks/security/

内容编辑：云安全实验室 浦明 责任编辑：肖晴