分类 云原生 下的文章

Istio自身服务的安全风险

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

阅读剩余部分 –

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

阅读剩余部分 –