阅读说明
本文适用于企业容器安全建设参考，篇幅较长可先浏览目录，跳转到关注的部分进行阅读。
背景
随着Kubernetes的广泛应用，生产效率提升的同时也逐渐暴露出了一些典型风险面，例如
Kubernetes及第三方应用漏洞利用
集群化部署在提高效率的同时也带来了新的攻击面。Kubernetes以及第三方应用不断出现新的漏洞，比如使用较广的Nginx Ingress、Helm等就曾出现过敏感信息泄露、权限提升等类型漏洞。在补丁修复完成前的窗口期，该如何及时发现漏洞利用行为呢？
高风险配置资源成为突破口
特权容器、挂载节点目录等场景增加了容器逃逸风险、信息泄露风险等。尽管很多合规配置检查都明确指出了这些风险，但实际总会因为历史包袱、特殊场景需求，导致业务环境中仍然存在这类资源。在业务优先的背景下，短时间下线所有风险配置业务较为困难，在业务改造窗口期，如何感知此类风险呢？
局部资源被控持续扩大失陷范围
随着混合云、多集群管控等形态趋势变化，攻击路径也更加复杂多样。对外提供服务的应用容器、配置不当的节点机、有集群凭证的办公网用户被钓鱼都可能是突破口。凭证泄露在攻击中屡试不爽，一个配置不当的普通账户往往会成为获得权限提升的突破口，如何及时发现横向移动中的蛛丝马迹及时止损呢？
Kubernetes Auditing拥有独特的视角，帮助我们看清集群层面的风险操作。阿里云云安全中心（以下简称云安全中心）容器安全从2020年开始支持Kubernets Audit日志入侵检测，经过两年的优化和攻击数据积累沉淀了一套丰富的检测模型，本文分享一些建设经验，抛砖引玉。
集群之眼-Kubernetes Auditing
Kubernetes提供了一种持续监控集群活动的可视化能力-审计(Auditing），能够记录kube-apiserver的交互响应，支持写入日志、自定义webhook等处理方式。
本文重点介绍如何利用Kubernetes Audit日志检测集群风险以及攻击行为，对webhook的方式不作展开。
云上Kubernetes集群告警现状
云安全中心支持接入Kubernetes Audit日志检测集群风险以及攻击行为，下图为不同安全事件类型两年内的告警事件量分布，其中”容器目录挂载配置不当”、”容器启动权限配置不当”事件量远超其他类型(这两类因达到图表高度上限，不代表真实比例)。
Kubernetes日志可以帮助我们发现多种安全事件，下面我们来认识这份日志并了解如何使用它。
五分钟看懂Kubernetes Audit日志
采集原理
Audit日志记录了kube-apiserver各种交互活动，kube-apiserver 可以看做集群的核心管控中心，提供了管理集群的REST API 接口，支持认证、鉴权、集群资源控制、集群状态变更等功能，并将 API 操作对象持久化存储到 etcd。以使用kubectl创建pod为例，主要流程可分为以下几步：
- kubectl向kube-apiserver发送创建pod的http post请求
- kube-apiserver收到请求，进行认证、鉴权等操作
- 鉴权通过后，请求被kube-apiserver路由到对应的api handler进行处理，并将配置参数持久化到etcd中
- kubelet根据配置参数在节点上创建pod
Auditing可以在第2步或第3步进行日志记录，目前支持指定以下四个阶段：
- RequestReceived：审计处理器接收到请求后，转给其他handler之前
- ResponseStarted：响应消息的头部发送后到响应消息体发送前这段时间内。通常为持续一段时间的操作如watch
- ResponseComplete：响应消息构建完成时
- Panic：发生错误时
如下图所示
日志详细程度通过指定审计级别（Level）来实现，常见审计级别有四种：
- None：不记录审计日志
- Metadata：记录请求的元数据，例如请求的user/method/时间/资源类型等，但不包括请求和响应具体内容
- Request：记录包括Metadata和请求，但不包括响应
- RequestResponse：记录包括Metadata、请求、响应
下面是一个简单的Audit日志采集策略样例，目的是详细记录集群内所有pod资源操作。
在实际业务场景下，通常需要更全面的采集策略，这里提供阿里云容器服务的示例作为参考https://help.aliyun.com/document_detail/91406.html。关于如何将数据上报到日志存储中心有很多公开方案，此处不作展开。
日志解读
下图是创建pod产生的一条json格式的Audit日志
这里根据实际使用经验，提供字段说明参考：
| 字段 | 类型 | 说明 | |
| apiVersion | string | Kubernetes对象api版本，比如ingress nginx从Kubernetes1.22版本开始只支持networking.k8s.io/v1，此前版本可使用networking.k8s.io/v1beta1。在检测一些特殊对象时需要考虑api多版本问题 | |
| kind | string | 请求类型，大多数场景固定为”Event” | |
| level | Level，基础类型string | 审计级别，代表日志完整度，为None值时不记录任何日志，为RequestResponse时记录最完整，参考前文介绍的四个程度None、Metadata、Request、RequestResponse | |
| auditID | UID，基础类型string | 请求唯一标识，可以作为告警等场景的唯一键，具体使用github.com/google/uuid生成 | |
| stage | Stage，基础类型string | 日志记录阶段，比如前文介绍的四个阶段ResponseComplete、RequestReceived、ResponseStarted、Panic | |
| requestURI | string | 客户端向kube-apiserver发送的请求URI，可以获取到API Handler信息 | |
| verb | string | 请求Kubernetes资源时，为特定动词如create，patch。 | 非资源请求时为小写的http方法，如get，post |
| user | UserInfo | 用户信息，包含了username、uid、groups等 | |
| impersonatedUser | UserInfo | 如果请求扮演了另一个用户，则为被扮演用户的信息 | |
| sourceIPs | 切片 | 请求发起者IP以及中间经过的代理IP | |
| userAgent | string | 客户端代理信息 | |
| objectRef | ObjectReference结构体 | 请求的目标对象的引用，比如操作ServicAccount时，该字段包含了ServicAccount所属命名空间、名称等信息。在list操作、非资源请求等情况下可能为空 | |
| responseStatus | Status结构体 | 返回的HTTP状态码及错误消息。Success状态下只返回状态码。Failure时包含报错信息 | |
| requestObject | Unknown类型结构体 | 请求对象的详细信息，json格式，当审计级别为Request或RequestResponse出现。对于非资源请求可能为空。 | 如果集群注册了修改原始请求的功能(version conversion/defaulting/admission/merging)，此时requestObject记录的仍是原始请求，比如使用mutiating webhook修改请求内容。 |
| responseObject | Unknown类型结构体 | 请求的响应，json格式，当审计级别为Response时出现 | |
| requestReceivedTimestamp | MicroTime | 请求到达kube-apiserver的时间 | |
| stageTimestamp | MicroTime | 请求到达当前审计阶段的时间 | |
| annotations | map[string]string | 注解，无固定格式的映射。通常可以从这个字段观察到请求处理链路经过了哪些模块处理、决策结果等，比如身份认证、鉴权以及准入控制等。 |
重点字段
Audit日志字段众多，在处理其产生的安全告警时该重点关注哪些字段呢？
- sourceIPS：该字段记录了请求发起者的IP以及中间经过的代理IP，起点为外网IP时可能指向攻击源头，起点为内网IP可能指向内部失陷的源头。可重点进行排查溯源。
- user：请求发起者的身份，关注身份不符合历史基线的行为，例如某普通应用的ServiceAccount突然被用于进入其他容器中执行命令、枚举读取secrets时，则有可能是应用的默认账户被用于权限提升、横向移动的导致。
- 操作资源：重点关注请求操作什么资源(objectRef)，以及动作(verb)，快速筛选出一些敏感的行为
- userAgent：客户端代理，用于辅助分析请求产生的来源，比如容器内通过curl发起的恶意请求，失陷dashboard发起的请求。下图展示了云上Kubernets集群请求的来源UserAgent按一周请求量排序的情况。可以看到来源于curl的请求量非常小
检测集群风险及攻击行为
在提升生产效率的同时，Kubernetes也引入了新的攻击面，贯穿容器内、主机节点、集群层面、镜像仓库等。Audit日志拥有独特的视角，帮助我们看清集群层面的操作行为。下面介绍一些攻防阶段中利用Audit日志发现风险和攻击行为的思路。
横向移动
横向移动这个词常在内网渗透中出现，在Kubernetes的场景下，由多集群、多节点、多应用组成的复杂环境就是一个大内网。以失陷容器或节点为跳板，收集集群信息，进一步提升权限和可控范围，最终实现控制单集群甚至多集群。下面介绍几种典型场景。
凭据泄露
一种较为常见的入侵场景是，攻击者通过web等外部可访问的服务入侵到容器内部后，首先摸清容器挂载的ServiceAccount具有哪些权限以进行权限提升或横向移动。例如下图中，尝试获取当前ServiceAccount权限信息
在没有kubectl的情况下，也可能会用curl等方式直接访问SelfSubjectRulesReview获取权限细节
经过上面的初步试探，发现只有读取pods、secrets、configmap等资源的权限，无修改以及进入容器执行命令等权限，于是列举并读取secrets，看是否有突破点
使用读取到的ServiceAccount的token，再次查看权限，发现这个新身份的权限很高，实现权限提升。
在真实业务场景中，特别是在一些规模较大且复杂的集群中，经常会出现账号权限配置不当的情况。除了配置检查，检测异常列举、读取、使用secrets等行为很重要。但日常运维中可能会出现类似行为，大量异常审计容易形成疲劳。
一种比较通用的解决方法是，重点关注一些可疑度更高的场景或者根据自身的业务环境，根据镜像/应用/命名空间等维度，结合UserAgent、sourceIPs、访问对象等信息，建立历史访问基线，关注基线外的行为。
下图为使用curl访问API SelfSubjectRulesReview获取当前账户权限信息时，产生的Audit日志
信息泄露漏洞
以为集群内服务提供外部访问能力的应用nginx-ingress为例，CVE-2021-25742是一个nginx-ingress的高危漏洞，当开启了Snippets特性且攻击者拥有创建或修改ingress实例的权限时，可以在 server 指令域注入lua代码读取secrets，造成多租户场景下的越权访问和集群维度的敏感信息泄露。如下图，漏洞环境下访问构造的路径读取读取Kubernetes的CA
我们可以从Audit日志中观察到requestObject.metadata.annotations中有关于server-snippet的设置，含有读取nginx ingress容器敏感信息的指令
另外还有两个原理较为类似的漏洞CVE-2021-25745、CVE-2021-25746，可重点关注spec.rules[].http.paths[].path以及metadata.annotations的异常代码。
可以预见的是这类风险会再次出现，虽然触发的位置和方式不同，但利用方式是相通的。因此可以通过检测常见的恶意命令，未雨绸缪。
移动到容器
进入容器执行命令是一种攻击者常用的方式，常出现在横向移动寻找更高权限、反弹SHELL等场景。
例如下图是一个真实的入侵案例发起的请求，攻击者进入容器并尝试下载启动一个恶意脚本。对于这类场景，可以利用Audit日志覆盖常见的恶意命令如反弹shell、下载程序并执行类操作等等。
下面是云安全中心在某真实入侵事件中利用Audit日志检测恶意命令执行的告警
另外值得注意的是，Audit日志无法记录建立exec通道之后的交互命令。原理参考以下exec命令通道建立的流程图，对于此类行为，基于容器内的命令采集更为重要，这涉及到运行时安全检测和防御，此处不作展开。
中间人攻击
CVE-2020-8554是一个中间人攻击(Man-in-the-MiddleAttack，简称“MITM攻击”)中危漏洞，在一个多租集群中，攻击者可以通过创建和更新Service实例的LoadBalancer、External IPs等字段来劫持集群中其他pod的流量。例如流传较广的一个案例是将集群的DNS流量劫持到攻击者控制的DNS服务中
可以重点关注Service服务创建、更新时externalIPs等参数的变动情况，比如服务的externalIPs指向业务不相关的公网IP段、已知域8.8.8.8、本地127.0.0.1来劫持节点流量等等。上面的yaml执行时将产生的Audit日志如下
权限提升
权限提升是Kubernetes攻防中的重要环节，不合理的配置是引入风险的主要原因之一。下面主要介绍使用Audit日志检测高风险资源的思路。
高风险配置
特权容器、可写模式挂载host节点系统目录等使用方式埋下了容器逃逸、信息泄露等隐患。
我们可以通过Audit日志动态捕获具有风险配置的资源创建，重点关注如Pod/ReplicaSet/ReplicationController/Deployment/StatefulSet/DaemonSet/Job/CronJob的创建和更新。
以创建一个具有SYS_ADMIN权限、挂载节点/etc目录的pod为例，它的Audit日志表现如下
通过获取容器capabilities，容器挂载节点目录等信息，对危险的capability、具有读写节点敏感目录权限的资源创建行为进行告警。
阿里云安全中心默认支持检测高风险配置资源启动，包括挂载节点目录、权限配置不当等等。
高权限用户
Kubernetes集群的用户大致可以分为两种：使用者是人的User、使用者是应用程序的ServiceAccount。
其中使用非常广泛、权限又比较高的组件的ServiceAccount往往是重点利用对象，如Helm、Cilium、Nginx Ingress、Prometheus等等。一些可重点关注的行为如：
- 绑定管理员权限
- 为ServiceAccount赋予了高权限，如创建容器、进入容器执行命令、枚举和读取secrets等权限
比如Helm 2这个版本曾出现过可借助Tiller的高权限为账户赋予cluster admin权限的问题
可以通过Audit日志对高权限绑定行为进行检测，相对于大多数安全场景，通常管理员级别的绑定事件数量并没有那么多，是可以人工运营的。ClusterRoleBinding的Audit日志表现如下
持久化
持久化的方式很多，这里重点介绍一下静态pod场景。
我们知道静态pod是一种仅存在于特定节点、不漂移、无法通过kube-apiserver进行管理的特殊pod。因此静态pod具有一定隐蔽性、持久化特性。在一些渗透场景如拥有节点特定目录写权限时，可以通过创建静态pod来运行攻击者指定的镜像。创建静态pod只需要指定一个本地或者远端的yaml文件即可。kubelet进程会定期扫描目录进行资源创建和销毁。
一个比较常见的疑问是，Audit日志是否能观测到静态pod的创建呢？
kubelet在创建静态Pod时，会为其创建一个mirror pod并上报给kube-apiserver，因此kube-apiserver可以观测到静态pod。但由于mirror pod是一个虚假的资源，对其进行操作实际上不会影响静态pod。我们可以从Audit日志中观测到静态Pod的信息，创建静态pod时，请求中的annotations带有kubernetes.io/config.mirror特征，下面是一个静态pod的创建请求样例
相对普通pod而言，静态pod的创建量级会小很多，一般都是为特定业务，因此从排白的角度看是比较有规律的。最常见的静态pod比如kube-apiserver等，参考/etc/kubernetes/manifests/目录下的配置
在早期的Kubernetes版本如1.6中，可能会出现静态pod已经在正常运行，但mirror pod创建失败导致静态pod不可见的报错场景，这也提供了一种绕过mirror pod达到更加隐蔽状态的思路。
蠕虫挖矿
在集群中启动恶意pod，是一种常见的占用资源、维持权限的方式。一些互联网传播的蠕虫入侵集群后，选择启动挖矿容器进行牟利。另一种常见的场景是是从dockerhub下载攻击工具镜像启动容器，使用容器内的黑客工具对集群或内网其他资源持续进行攻击。很多镜像单从镜像仓库地址、启动命令参数就可以判断为具有危害的镜像，比如挖矿、流行的攻击工具套件。虽然这种匹配已知特征的方式简单粗暴，容易绕过，但在很多场景下效果不错。
以创建挖矿pod为例，可以从requestObject获得容器启动使用的镜像、启动参数进行恶意特征匹配，参考下面的日志表现
异常访问
对于有公网连接端点的集群，每天可能会接受来自公网的大量访问，一个比较极端的场景是，给匿名用户赋予了集群管理员的权限，一旦集群存在可通过公网访问入口，就等同于直接获取到整个集群的控制权限。如下面这个为匿名用户绑定cluster admin之后，匿名用户可从外网访问并管理集群的案例
下面是匿名用户发起请求时的Audit日志表现
对于这个场景，可以关注来自公网IP的匿名用户高权限行为，或者用前文提到的高权限账户配置行为。这种情况在早期生产和测试集群环境居多，现在已经逐渐收敛。
对于暴露在公网的集群，通常情况下运维人员会设置安全组缩小来源IP范围来提升安全性。但攻击渠道总是复杂多样的，例如处在信任IP段、保存了集群管理凭证的办公网机器失陷。这种场景的检测难点在于同正常运维行为高度相似。相比检测，更多的被应用于入侵之后的溯源，串联起整条攻击路径、快速止血。
以子之矛，攻子之盾
在使用日志的同时，我们需要重视日志组件本身的安全性，及时修复相关漏洞。Kubernetes历史上曾出现过日志泄露敏感信息的问题(CVE-2020-8564/CVE-2020-8565/CVE-2020-8566)。CVE-2020-8564是一个kubelet组件漏洞，在漏洞版本的环境下，日志级别≥4且触发私有镜像仓库配置解析报错时，docker config凭证通过报错信息写入了日志，如下图漏洞环境下，因仓库解析报错从日志中读到了的仓库凭证信息
总结
随着业务部署管理逐渐向容器集群的形态演进，攻防对抗也随之改变并产生了复杂攻击路径与组合技。安全贯穿端点、集群、供应链等等。仅保护其中一个面是远远不够的。Kubernetes Auditing拥有独特的视角，帮助我们看清集群层面风险操作。
云安全中心容器安全产品默认支持Kubernetes Audit日志入侵检测，经过两年的Kubernetes Audit攻击数据积累沉淀了一套丰富的检测模型，配合镜像扫描、集群主动防御、运行时入侵检测和防御、网络微隔离等功能构建基于容器全生命周期的安全防护体系，保障云原生安全。