分类 云原生 下的文章

Service Mesh中的iptables流量劫持

随着软件架构不断的演进,更加快捷部署大型复杂应用成为了人们关注的方向。近几年Service Mesh开始不断出现在大家的视野里,越来越多的大厂开始对其进行实践。事实上在Service Mesh发展中核心就是不断对Sidecar模式配备更加完善的流量管理解决方案。
在Service Mesh中Sidecar是透明的,开发者对其无感知的,而其中对于流量最关键的一步就是Sidecar进行的流量劫持,那么Sidecar又是如何进行流量劫持呢?最常见的方式就是iptables,本文将会带你了解iptables,同时明白Istio中是如何使用iptables进行流量劫持。

阅读剩余部分 –

Kubernetes中使用Helm2的安全风险

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可能造成的安全风险进行讨论。

阅读剩余部分 –