浅谈云原生安全建设
2022-10-19 17:55:39 Author: leveryd(查看原文) 阅读量:15 收藏

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

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

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

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

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

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

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 DROP
iptables -I OUTPUT -m state --state NEW -s 10.233.69.0/24 -d 172.16.0.0/12 -j DROP

iptables -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的效果。

镜像裁剪和运行时监控

https://containerjournal.com/features/sysdig-adds-ability-to-make-container-runtimes-immutable 提到sysdig产品提供了一个能力,能让"容器只运行白名单程序"。

在 https://github.com/falcosecurity/falco/blob/35db0b4a24344bc6c24022555f7d8531ad925136/rules/falco_rules.yaml#L3018 可以看到规则。

包括两种告警策略:

  • 发现chmod时
  • 发现open创建的文件有执行权限时

如果一个镜像裁剪到只留下必要的可执行文件,再加上面的运行时监控,就能削减很大的攻击面、容易发现威胁。

蚂蚁集团针对 K8s 中 Secret 安全防护的实践与探索[8] 中提到针对secret对象实施的数据安全方案,相比于只在etcd中加密secret,还保护了apiserver内存中没有secret。个人感觉大部分公司没有需求和动力做这个建设。

https://github.com/knownsec/KCon/blob/master/2021/kubernetes中的异常活动检测.pdf paper中提到通过kubernetes的审计机制、创建蜜罐账号来发现集群中的攻击行为。

总结了code、container、cluster三层的风险和缓解措施,对于其中我自己觉得重要或者有意思的部分内容做了多一点说明。

做云原生安全检测产品、云安全建设时,kubernetes攻防矩阵[9] 也是一个值得参考的模型。

参考资料

[1]

Kubernetes 下零信任安全架构分析: https://zhuanlan.zhihu.com/p/98874541

[2]

18年黑掉DigitalOcean的k8s服务案例: https://www.4armed.com/blog/hacking-digitalocean-kubernetes/

[3]

Shopify的hackerone报告: https://hackerone.com/reports/341876

[4]

neargle大佬的总结: https://github.com/neargle/my-re0-k8s-security/

[5]

NetworkPolicy: https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

[6]

The Route to Host:从内核提权到容器逃逸: https://cloud.tencent.com/developer/article/1981030

[7]

lkrg: https://github.com/lkrg-org/lkrg

[8]

蚂蚁集团针对 K8s 中 Secret 安全防护的实践与探索: https://www.infoq.cn/article/ycdctxabbgqjdfckiy0y

[9]

kubernetes攻防矩阵: https://developer.aliyun.com/article/765449


文章来源: http://mp.weixin.qq.com/s?__biz=MzkyMDIxMjE5MA==&mid=2247485243&idx=1&sn=aa937a2bbdba68c4002ad8f491d63e02&chksm=c197008af6e0899c2f08f2d0312d51b300fb4e8bb82c76f67d0bf1971edb5ef3d0fb1a21d401#rd
如有侵权请联系:admin#unsafe.sh