helm安装istio_深度解析Istio系列之安全模块篇

 点击“博云技术社区”，获取最新技术分享

单体应用拆分为微服务之后，提高了开发效率，增加系统系统稳定性，提高运维效率等等一系列的好处，但随之也带来了安全方面的风险，之前都是本地调用，现在都改为走网络协议调用接口，今天着重介绍的是微服务架构中的新贵Istio中安全模块分析，Istio安全的三大目标：

• 默认安全(Security by default)：应用程序代码和基础结构无需更改。

• 深度防御(Defense in depth)：与现有安全系统集成，提供多层防御。

• 零信任网络(Zero-trust network)：在不受信的网络上，构建安全解决方案。

架构

如上图，Istio安全涉及到组件有：

• Citadel 用于密钥和证书的管理。

• Proxy 实现客户端与服务器端安全通信。

• Pilot 将授权策略和安全命名信息分发给代理。

• Mixer：校验授权和审计。

Istio 身份

身份信息

身份信息是安全基础架构的基本概念，在服务和服务的通信开始前，双方必须用其身份信息交换凭证，以达到相互认证的目的，根据安全信息达到鉴权的目的，同时根据身份信息可以进行审计，在kubernetes的环境下Istio身份标识使用Service Account。

PKI

PKI(Public Key Infrastructure)建立在Istio citadel 之上，Istio 使用 X.509 证书来携带 SPIFFE 格式的身份信息，PKI 还可以大规模自动化地进行密钥和证书轮换。

证书生成流程

基于kubernetes环境下证书生成流程如下：

citadel同时也会监听每个证书的生命周期，通过重写 Kubernetes secret 自动轮换证书。Pilot生成安全信息即授权信息，Pilot将授权信息分发给envoy每个命名空间下有个default serviceaccount，citadel会为它创建一个名为istio.default的secret。

[root@kube01 ~]$ kubectl -n foo get secrets 

NAME                  TYPE                                  DATA      AGE 

default-token-bdpmg   kubernetes.io/service-account-token   3         8d 

istio.default         istio.io/key-and-cert                 3         8d

默认在该命名空间下新建的istio应用都使用该secret。

istio-certs:

     Type:        Secret (a volume populated by a Secret)

     SecretName:  istio.default

     Optional:    true

当为deployment指定了非默认serviceaccount，则秘钥也将使用新的secret。

istio-certs:

     Type:        Secret (a volume populated by a Secret)

     SecretName:  istio.bookinfo-productpage

     Optional:    true

认证

Istio提供两种类型的身份验证：

• 传输身份验证，也称为服务到服务身份验证：验证直接客户端进行连接。Istio提供相互TLS 作为传输身份验证的完整堆栈解决方案。

• 源身份验证，也称为最终用户身份验证：验证将请求作为最终用户或设备的原始客户端。

具体信息参见官网，本文章主要介绍第一种。

相互 TLS身份验证(mTLS)

mTLS本身流程如下图所示：

在Istio握手期间，客户端envoy还进行安全命名检查，验证服务器证书中提供的服务账户是否有权限运行目标服务。