浅谈云原生安全建设

背景

我想总结一下我理解的云原生安全，内容源于我的工作经历、我看到的公开分享、最近面试时被问到的。

kubernetes官方提出"你可以分层去考虑安全性，云原生安全的4个C分别是云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)"，我也是从这个"4c模型"来理解云原生安全的。

kubernetes描述的4c模型 https://kubernetes.io/zh-cn/docs/concepts/security/overview/

下面就向你介绍我用"4c模型"怎么理解云原生安全的，在每一层描述风险和对应的缓解措施。

第一个C：代码(Code)

代码风险有两种，编码和第三方依赖，缓解这两种安全风险也有很多手段。

其中我觉得安全编码最重要的是在web框架提供统一的默认安全能力，然后通过检查业务代码有没有使用框架提供的不安全api来收敛风险。就比如说orm框架预编译避免sql注入、react/vue等前端框架能将数据和代码分离来避免xss。

第二个C：容器(Container)

kubernetes的命名空间并没有网络隔离的效果，默认情况下pod之间能互相访问、pod能访问宿主机、pod能访问vpc。当pod被getshell、pod服务存在ssrf漏洞时，就能攻击其他服务。

容器网络中也可以arp欺骗，有师傅分享过实战案例，可以见 https://github.com/knownsec/KCon/tree/master/2019/25日/针对Docker容器网络的ARP欺骗与中间人攻击.pdf

镜像中的基础镜像、安装的软件有可能版本比较低，存在历史漏洞。这种风险不一定能变成漏洞利用，提供镜像的服务商可能更关注这类风险。风险更大的场景是镜像中存在研发运维留在镜像中的敏感信息，比如pod中的应用想要和云服务通信时需要有ak/sk来签名或者sts，所以反编译应用或者查看环境变量后能看到ak/sk或者sts。

身份认证

pod中的进程可以用/var/run/secrets/kubernetes.io/serviceaccount/token文件中的服务账号作为集群中的身份，这里的风险是token文件是明文存储的，并且也没有办法确保所有pod中的应用api都实现认证鉴权。

Kubernetes 下零信任安全架构分析[1] 文章中提到蚂蚁k8s集群中api服务认证和授权的设计，在服务网格场景中，通过sidecar、pod label、证书或者jwt来在请求中带上身份信息、通过sidecar校验身份和授权。

对于这个设计我有很多不明白的地方，比如 "在pod里curl其他应用，sidecar也会带上身份信息？这样不就相当于伪造身份了吗"。

网络隔离

风险是什么呢？

网络隔离是我认为"投入产出比最高、优先级最高"的一个事情。

默认情况下，pod是可以访问"k8s集群网络"、"宿主机网络"：

可以访问宿主机上的服务
可以访问"宿主机所在网络"的服务
可以访问集群service、pod，并且不受"kubernetes namespace"限制

kubernetes namespace不是内核的namespace，而是"项目"的概念。一个项目应该属于一个 kubernetes namespace。

从pod攻击集群有很多手段，举两个例子。

如果集群部署在云虚机上，在容器中就可以访问特殊网段的"元数据服务"。在18年黑掉DigitalOcean的k8s服务案例[2]中，攻击者通过metadata中的etcd凭证拿下k8s集群。在Shopify的hackerone报告[3]中，攻击者通过ssrf漏洞获取谷歌云metadata中的集群证书信息。

在容器中也可以攻击宿主机上的服务。举一个我以前报告的漏洞为例，通过"容器中挂载宿主机根目录到容器后写入ssh key，然后在容器中连接宿主机ssh"我逃逸到了宿主机。当时我想如果业务方"禁止容器访问宿主机ssh服务"，逃逸过程就会受影响。

挂载宿主机目录后，也可以用static pod、cron服务来做攻击。怎么预防和发现这种利用手段是另外一个话题。

攻击者也可以在容器中对vpc、内网、集群服务做漏洞扫描。更多的kubernetes下的攻击手法和案例可以阅读 neargle大佬的总结[4]

怎么做网络隔离呢？

一个比较常见的网络隔离效果如下：

对pod的限制：

pod不能主动访问"宿主机所在的内网"
pod不能主动访问宿主机
pod不能主动访问虚机metadata
pod能主动访问外网
同一个"k8s namespace"下pod网络可以互通，不同"k8s namespace"下pod网络不通

同时，不应该限制宿主机网络：

node可以访问master
node可以访问外网

kubernetes的NetworkPolicy[5] 并不能完全实现上面要求的网络隔离效果，因为它的默认策略是拒绝，用户只能加白。所以我们还需要借助其他的手段来做网络隔离，比如iptables。

一个简单的例子如下：在宿主机上执行下面的iptables (假设pod网段是10.233.69.0/24)

iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 192.168.0.0/16 -j DROP   // pod不能主动访问"宿主机所在的内网"iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 10.0.0.0/8 -j DROPiptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 172.16.0.0/12 -j DROPiptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 169.254.169.254/32 -j DROP    // pod不能主动访问metadata(华为云/百度云/amazon/azure)iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 100.100.100.200/32 -j DROP    // pod不能主动访问metadata(阿里云)iptables -I OUTPUT -d 10.233.69.0/24 -j ACCEPT // 容器网络加白iptables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

利用内核漏洞逃逸的检测和阻断

The Route to Host：从内核提权到容器逃逸[6] 提到多种利用内核漏洞做容器逃逸的手段，比如修改容器进程task_struct数据结构的nsproxy、cred字段，修改命名空间和capability。

有针对类似利用手法做检测的方案，比如 lkrg[7]项目，检查进程cred等字段是否改变。

https://i.blackhat.com/USA-22/Wednesday/US-22-Fournier-Return-To-Sender.pdf paper中提到针对内核漏洞rop利用手法，通过eBPF检查commit_creds(prepare_kernel_cred(0))函数调用栈中是否有来自用户态空间的地址，达到类似smep、smap的效果。