Istio是目前最受关注的服务网格之一，越来越多的公司开始落地Service Mesh架构，并将已有的系统接入Service Mesh。同时随着零信任网络的发展，东西向，南北向流量都需要提供足够的安全保护，因为Istio自身提供了多种安全特性，所以也出现不少基于Istio的零信任架构。在安全中通常关注的重点是南北流量，而我们应该认识到，在云原生的环境下，东西流量安全也应该受到足够的重视。
在Istio默认的配置中，其在集群内暴露了许多未授权和明文传输的服务。通常情况下，这会引起攻击者的注意，当恶意攻击者进入被控制的容器或发现SSRF漏洞后，往往可以利用这些自身的服务扩大攻击范围。

阅读剩余部分 –

Kubernetes是一个强大的容器调度系统，通常我们会使用一些声明式的定义来在Kubernetes中部署业务。但是当我们开始部署比较复杂的多层架构时，事情往往就会没有那么简单，在这种情况下，我们需要编写和维护多个YAML文件，同时在编写时需要理清各种对象和层级关系。这是一个比较麻烦的事情，所以这个时候Helm出现了。

我们熟悉的Python通过pip来管理包，Node.js使用npm管理包。那么在Kubernetes，我们可以使用Helm来管理。它降低了使用Kubernetes的门槛，对于开发者可以很方便的使用Helm打包，管理依赖关系，使用者可以在自己的Kubernetes通过Helm来一键部署所需的应用。
对于Helm本身可以研究的安全风险可以从很多角度来看比如Charts，Image等，详细的内容可以来看CNCF webinars关于Helm Security的一个分享（https://www.cncf.io/webinars/helm-security-a-look-below-deck/）
本篇文章主要讨论的是Helm2的安全风险，因为在Helm2开发的时候，Kubernetes的RBAC体系还没有建立完成，Kubernetes社区直到2017年10月份v1.8版本才默认采用了RBAC权限体系，所以Helm2的架构设计是存在一定安全风险的。Helm3是在Helm2之上的一次大更改，于2019年11月份正式推出，同时Helm2开始退出历史舞台，到2020年的11月开始停止安全更新。但是目前网络上主流依然为关于Helm2的安装配置文章，所以我们这里将对使用Helm2可能造成的安全风险进行讨论。

阅读剩余部分 –