CNCF（云原生计算基金会 Cloud Native Computing Foundation）在对云原生定义的描述中提到 “云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API”；
我们今天所聊到的漏洞和利用手法也紧紧围绕着上述的几类技术和由云原生相关技术所演化出来的多种技术架构进行，包括但不限于容器、服务网格、微服务、不可变基础设施、声明式 API、无服务架构、函数计算、DevOps 等，并涉及研发团队在使用的一些云原生开源组件和自研、二次开发时常见的安全问题。不在 “云原生安全” 这个概念上做过多的延伸和扩展，且提及所有的安全漏洞都在 “腾讯蓝军” 对内对外的攻防演练和漏洞挖掘中有实际的利用经验积累。
在实际的攻防中我们所进行的攻击路径并非完全契合在 CIS2020 上总结的攻击模型：
因为大部分情况下我们遇到的内网并非完全基于容器技术所构建的，所以内网的起点并不一定是一个权限受限的容器，但攻击的方向和目标却大同小异：为了获取特定靶标的权限、资金和数据，我们一般需要控制更多乃至全部的容器、主机和集群。
也由于业界云原生实践的发展非常迅速，虽然进入内网之后我们所接触的不一定是全是 Kubernetes 所编排下的容器网络和架构，但基于云原生技术所产生的新漏洞和利用手法往往能帮蓝军打开局面。
举个例子，当我们通过远控木马获取某个集群管理员 PC 上的 kubeconfig 文件 （一般位于 ~/.kube/config 目录），此时我们就拥有了管理 Kubernetes 集群的所有能力了，具体能做的事情后面会有更详细的探讨。
如果此时该集群没有设置严格的 security policy 且目标企业的 HIDS 没有针对容器特性进行一定策略优化的话，那创建一个能获取 NODE 权限的 POD 或许就是一个不错的选择，因为只有这样获取的 shell 才能更方便的在容器母机上进行信息收集，例如 strace 母机 sshd 进程抓取我们想要的用户名和密码、使用 tcpdump 抓取内网系统的管理员登录态等，目前正在运行的容器一般是没有这些权限的。
以下是这种情况下我们常用的 POD yaml 配置：
如果对 Kubernetes 的 POD 不熟悉，其实上述的配置就比较类似于在想要 ROOT 权限的业务服务器上执行以下 docker 命令:
docker -H ${host_docker_sock} run -d -it –name neartest_Kubernetes_hashsubix -v “/proc:/host/proc” -v “/sys:/host/sys” -v “/:/near_sandbox” –network=host –privileged=true –cap-add=ALL alpine:latest /bin/sh -c tail -f /dev/null
执行的结果和作用如下 (注：所有的挂载和选项并非都必须，实战中填写需要的权限和目录即可，此处提供一个较全的参考)：
当然上述大部分配置都会被多租户集群下的 Kubernetes Security Policy 所拦截，且如果目前主机上的 HIDS 有一定容器安全能力的话，这类配置的容器创建行为也比较容易会被标记为异常行为。
不过，显然我们在真实的对抗中如果只是想达到执行 strace 抓取 sshd 的目的，配置可以更加简化一点，只需添加 SYS_PTRACE 的 capabilities 即可，我在演习中也正是这么做的。
因为具有 SYS_PTRACE 权限的容器并且进行 kubectl exec 的行为在实际的研发运维流程中非常常见，是 HIDS 比较不容易察觉的类业务型操作；另外也可以寻找节点上已有该配置的容器和 POD 进行控制，同样是不易被防御团队所察觉的。
接下来我们也会一个个讨论这类漏洞和手法和我们实际在对抗中遇到的场景。同时，无论是在 CNCF 对云原生的定义里，还是大家对云原生技术最直观的感受，大部分技术同学都会想到容器以及容器编排相关的技术，这里我们就以容器为起始，开启我们今天的云原生安全探索之旅吧~
