随着云原生技术的普及，其暴露出来的攻击面也被黑客们念念不忘，相关的攻击技术也跟着被“普及”，自动化漏洞利用攻击工具更是如雨后春笋般出现在GitHub开源平台，其中比较有代表性的如cdk-team/CDK。其是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

在漏洞利用门槛如此低廉的今天，作为企业安全的建设者（搬砖人），除了考虑部署容器层面运行时检测平台，在k8s api-server层面，启用日志审计功能，也是一个成本低廉又高效发现入侵攻击的途径。

通过对api-server的日志进行审计分析，对于攻击者的信息收集行为，部署k8s cronjob后门、利用rbac做权限提升等持久化攻击行为都能及时的发现并输出告警。

Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。 它能帮助集群管理员处理以下问题：

- 发生了什么？- 什么时候发生的？- 谁触发的？- 为什么发生?- 在哪观察到的？- 它从哪触发的？- 它将产生什么后果？

审计日志示例（图片来自参考[5]

如何开启日志审计

1、api-server命令行启动时，添加如下参数

--audit-policy-file=/etc/kubernetes/audit/audit-default-policy.yaml        # 审计策略文件--audit-log-path=/data/log/audit/audit.log                                 # kube-apiserver 输出的审计日志文件，此处以日志文件落地的方式做日志收集--audit-log-maxbackup=10                                                   # kube-apiserver 审计日志文件的最大备份数量--audit-log-format=json                                                    #日志保存格式--audit-log-maxage=10                                                      #日志最大保留时间--audit-log-maxsize=500                                                    # 单个日志文件最大为500M

2、kubeadm启动时

修改api-server配置文件/etc/kubernetes/manifests/kube-apiserver.yaml，增加如下内容

--audit-policy-file=/etc/kubernetes/audit/audit-default-policy.yaml--audit-log-path=/data/log/audit/audit.log --audit-log-maxbackup=10 --audit-log-format=json--audit-log-maxage=10--audit-log-maxsize=500 

若攻击者通过各种手段拿到一个容器shell环境后，下一步必然是利用这个容器进行信息收集，获取更多敏感信息或机器资源，此时，CDK作为一款自动化的攻击工具，就让整个攻击过程如虎添翼，大大提高攻击效率。

作为甲方安全的守护者，从安全建设的角度，如何有效及时的发现攻击者的入侵行为，是一个无法避开的问题。本文通过观察cdk的攻击行为，从k8s日志审计的角度罗列一些入侵检测的常见规则。

目前，针对于日志的审计分析，我们落地方案的整个流程为：

注：下列场景，仅限于原生的CDK行为检测，如果攻击者具备开发能力，修改对应特征，可以绕过对应的检测规则。

CDK在容器内主要收集以下信息：

工具在镜像内运行，其信息收集的结果执如下：

从图上可知，信息收集的整个过程，存在与api-server交互的仅有网络探测部分，总共会向api-server发送三条请求，分别为API-server、namespace、api信息探测。

audit.log

{    "kind": "Event",    "apiVersion": "audit.k8s.io/v1",    "level": "Metadata",    "stage": "ResponseComplete",    "requestURI": "/",    "verb": "get",    "user": {        "username": "system:anonymous",        "groups": [            "system:unauthenticated"        ]    },    "sourceIPs": [        "172.18.0.2"    ],    "userAgent": "Go-http-client/1.1",    "responseStatus": {        "metadata": {},        "status": "Failure",        "reason": "Forbidden",        "code": 403    },    "requestReceivedTimestamp": "2023-02-02T08:29:12.189459Z",    "stageTimestamp": "2023-02-02T08:29:12.189553Z",    "annotations": {        "authorization.k8s.io/decision": "forbid",        "authorization.k8s.io/reason": ""    }}

audit.log

{    "kind": "Event",    "apiVersion": "audit.k8s.io/v1",    "level": "Metadata",    "auditID": "41770e7a-1827-4a14-860f-a812d3db1647",    "stage": "ResponseComplete",    "requestURI": "/api/v1/namespaces",    "verb": "list",    "user": {        "username": "system:serviceaccount:test:default",        "uid": "63b8dd88-88dd-4426-bdd1-7966906dc0d5",        "groups": [            "system:serviceaccounts",            "system:serviceaccounts:test",            "system:authenticated"        ]    },    "sourceIPs": [        "172.18.0.2"    ],    "userAgent": "Go-http-client/1.1",    "objectRef": {        "resource": "namespaces",        "apiVersion": "v1"    },    "responseStatus": {        "metadata": {},        "status": "Failure",        "reason": "Forbidden",        "code": 403    },    "requestReceivedTimestamp": "2023-02-02T08:29:12.205422Z",    "stageTimestamp": "2023-02-02T08:29:12.205485Z",    "annotations": {        "authorization.k8s.io/decision": "forbid",        "authorization.k8s.io/reason": ""    }}

跟namespace类似，只不过requestURI为/apis

综上， 上述日志中可概述为，当cdk在做信息收集时，会向api-server请求3次，分别访问/，/apis，/api/v1/namespaces，可根据这些特征做告警规则

1、userAgent: Go-http-client/1.1      # CDK特定的userAgent，此时，该字段为主要特征2、responseStatus.code: 403           #默认serviceaccount无权限时 api-server返回的状态码3、requestURI: /                      # 访问根目录

Exploit模块包含的功能：

其中，容器逃逸层面，一般是不需要与api-server做交互的，也就不会留下日志。但部分容器逃逸手段是利用错误配置的pod在创建时实施攻击。因此，容器逃逸的检测必须前置到容器创建时，记录下应用请求的权限，然后结合运行时入侵检测做进一步监控。

当一个拥有privilege、sys_admin、network、ipc等特殊权限的pod创建时，它的日志记录是这样的。

audit.json

{    "kind": "Event",    "apiVersion": "audit.k8s.io/v1",    "level": "RequestResponse",    "stage": "ResponseComplete",    "requestURI": "/api/v1/namespaces/testpods/pods",    "verb": "create",    "user": {        "username": "kubernetes-admin",        "groups": [            "system:masters",            "system:authenticated"        ]    },    "sourceIPs": [        "172.18.0.1"    ],    "userAgent": "kubectl1.16.15/v1.16.15 (darwin/amd64) kubernetes/2adc8d7",    "objectRef": {        "resource": "pods",        "namespace": "testpods",        "name": "testpod",        "apiVersion": "v1"    },    "responseStatus": {        "metadata": {},        "code": 201    },    "responseObject": {        "kind": "Pod",        "apiVersion": "v1",        "metadata": {            "name": "testpod",            "namespace": "testpods",            "selfLink": "/api/v1/namespaces/testpods/pods/testpod",            "uid": "e717d204-7e6d-4608-998b-648a8667e8e1",            "resourceVersion": "13517",            "creationTimestamp": "2023-02-02T09:51:10Z",            "labels": {                "creator": "zhiye",                "team": "teamf"            }        },        "spec": {            "volumes": [                {                    "name": "rootfs",                    "hostPath": {                        "path": "/",                        "type": ""                    }                }            ],            "containers": [                {                    "name": "trpe",                    "image": "alpine",                    "command": [                        "/bin/sh",                        "-c",                        "tail -f /dev/null"                    ],                    "resources": {},                    "volumeMounts": [                        {                            "name": "default-token-mm6s8",                            "readOnly": true,                            "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount"                        }                    ],                    "terminationMessagePath": "/dev/termination-log",                    "terminationMessagePolicy": "File",                    "imagePullPolicy": "Always",                    "securityContext": {                        "capabilities": {                            "add": [                                "SYS_ADMIN"                            ]                        },                        "privileged": true                    }                }            ],            "restartPolicy": "Always",            "terminationGracePeriodSeconds": 30,            "dnsPolicy": "ClusterFirst",            "serviceAccountName": "default",            "serviceAccount": "default",            "hostNetwork": true,            "hostPID": true,            "hostIPC": true,            "securityContext": {},            "schedulerName": "default-scheduler",            "tolerations": [                {                    "key": "node.kubernetes.io/not-ready",                    "operator": "Exists",                    "effect": "NoExecute",                    "tolerationSeconds": 300                },                {                    "key": "node.kubernetes.io/unreachable",                    "operator": "Exists",                    "effect": "NoExecute",                    "tolerationSeconds": 300                }            ],            "priority": 0,            "enableServiceLinks": true        },        "status": {            "phase": "Pending",            "qosClass": "BestEffort"        }    },    "requestReceivedTimestamp": "2023-02-02T09:51:10.632436Z",    "stageTimestamp": "2023-02-02T09:51:10.660958Z",    "annotations": {        "authorization.k8s.io/decision": "allow",        "authorization.k8s.io/reason": ""    }}

从日志上可以看出，针对于错误配置导致的逃逸，我们可以关注以下几个日志字段,制定告警规则。

responseObject.spec.volumes                                         # 检测敏感卷，是否挂载docker.sock等responseObject.spec.containers.volumeMounts                         # 检测敏感挂载，是否挂载docker.sock等responseObject.spec.containers.securityContext.capabilities.add     # 是否使用SYS_ADMIN权限，（字段嵌套这么多层，真的得吐槽responseObject.spec.containers.securityContext.privileged           # 检测是否为特权pod容器responseObject.spec.hostNetwork                                     # 是否使用宿主机网络responseObject.spec.hostPID                                         # 是否使用宿主机hostPIDresponseObject.spec.hostIPC                                         # 是否共享宿主机内存responseObject.spec.serviceAccount                                  # 是否使用特殊的serviceaccount  默认为default

此功能为端口扫描+指纹识别，不涉及与API交互,未产生日志。

与api-server交互的为secrets、config和psp，如果是自动获取的话，cdk会发送两次请求，分别使用匿名账户和当前serviceaccout做list动作。

下边列举些主要特征

requestURI: /api/v1/secrets，requestURI: /api/v1/configmapsrequestURI: /apis/policy/v1beta1/podsecuritypoliciesuserAgent: Go-http-client/1.1user.username: "system:anonymous"responseStatus.code: 403"verb": "list"

RBAC权限绕过

日志如下

{    "kind": "Event",    "apiVersion": "audit.k8s.io/v1",    "level": "RequestResponse",    "auditID": "bfc643d6-8337-434e-9dec-ba41dd36bfa7",    "stage": "ResponseComplete",    "requestURI": "/api/v1/namespaces/kube-system/pods",    "verb": "create",    "user": {        "username": "system:serviceaccount:test:default",        "uid": "63b8dd88-88dd-4426-bdd1-7966906dc0d5",        "groups": [            "system:serviceaccounts",            "system:serviceaccounts:test",            "system:authenticated"        ]    },    "sourceIPs": [        "172.18.0.3"    ],    "userAgent": "Go-http-client/1.1",    "objectRef": {        "resource": "pods",        "namespace": "kube-system",        "apiVersion": "v1"    },    "responseStatus": {        "metadata": {},        "status": "Failure",        "reason": "Forbidden",        "code": 403    },    "responseObject": {        "kind": "Status",        "apiVersion": "v1",        "metadata": {},        "status": "Failure",        "message": "pods is forbidden: User \"system:serviceaccount:test:default\" cannot create resource \"pods\" in API group \"\" in the namespace \"kube-system\"",        "reason": "Forbidden",        "details": {            "kind": "pods"        },        "code": 403    },    "requestReceivedTimestamp": "2023-02-03T09:56:24.061825Z",    "stageTimestamp": "2023-02-03T09:56:24.061888Z",    "annotations": {        "authorization.k8s.io/decision": "forbid",        "authorization.k8s.io/reason": ""    }}

由上可发现如下特征：

Pod内serviceaccount无权限的情况requestURI: /api/v1/namespaces/kube-system/podsuserAgent: Go-http-client/1.1responseStatus.code: 403 
Pod内serviceaccount有权限的情况requestURI: /api/v1/namespaces/kube-system/podsresponseObject.metadata.selfLink: /api/v1/namespaces/kube-system/pods/cdk-rbac-bypass-create-pod  responseObject.metadata.spec.containers.args: *cat /run/secrets/kubernetes.io/serviceaccount/token* verb: create

部署daemonset后门

源码是这样定义的（参考[6]）：

体现到日志中，有以下几个点：

objectRef.name: cdk-backdoor-daemonsetobjectRef.namespace: kube-systemresponseObject.metadata.selfLink: /apis/apps/v1/namespaces/kube-system/daemonsets/cdk-backdoor-daemonsetresponseObject.spec.template.spec.volumes.hostPath.path: /responseObject.spec.template.spec.containers.name: cdk-backdoor-podresponseObject.spec.template.spec.containers.securityContext[capabilities:ptivileged]:如图上所示responseObject.spec.template.spec.[hostNetwork|hostPID]: true

部署K8S CronJob

CDK源代码是这样定义的（参考[7]）：

体现在日志中，特征有以下几点：

requestURI: /apis/batch/v1beta1/namespaces/kube-system/cronjobsverb: createobjectRef.name: cdk-backdoor-cronjobresponseObject.matadata.name: cdk-backdoor-cronjobresponseObject.matadata.selfLink: /apis/batch/v1beta1/namespaces/kube-system/cronjobs/cdk-backdoor-cronjobresponseObject.spec.jobTemplate.spec.template.spec.containers.name: cdk-backdoor-cronjob-container

部署影子k8s api-server

在pod权限足够的情况下，通过创建shadow api-server做权限维持，详情见参考[4]

在非二开的情况下，通过k8s日志升级可检测以下几个字段

objectRef.name: *-shadow-*responseObject.metadata.labels.component: kube-apiservershadowresponseObject.spec.containers.command: "--secure-port=9444"

因为漏洞利用部分，动作都普遍较大，因此可观测字段已不仅仅局限于userAgent,其特征均比较明显，极富有工具本身特色

此处需要关注的（跟api-server有交互的）为kcurl命令，此命令可借助高权限serviceaccount账户列举/使用k8s资源。

执行./cdk kcurl default get 'https://10.96.0.1:443/api/v1/nodes' ，日志内容如下：

audit.log

{    "kind": "Event",    "apiVersion": "audit.k8s.io/v1",    "level": "Metadata",    "auditID": "418cafa5-2c1e-4fbf-b086-3d68e321d2bb",    "stage": "ResponseComplete",    "requestURI": "/api/v1/nodes",    "verb": "list",    "user": {        "username": "system:serviceaccount:test:default",        "uid": "63b8dd88-88dd-4426-bdd1-7966906dc0d5",        "groups": [            "system:serviceaccounts",            "system:serviceaccounts:test",            "system:authenticated"        ]    },    "sourceIPs": [        "172.18.0.3"    ],    "userAgent": "Go-http-client/1.1",    "objectRef": {        "resource": "nodes",        "apiVersion": "v1"    },    "responseStatus": {        "metadata": {},        "code": 200    },    "requestReceivedTimestamp": "2023-02-06T09:51:51.790260Z",    "stageTimestamp": "2023-02-06T09:51:51.791075Z",    "annotations": {        "authorization.k8s.io/decision": "allow",        "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"defaultadmin\" of ClusterRole \"cluster-admin\" to ServiceAccount \"default/test\""    }}

日志中annotations.authorization.k8s.io/reason给出了允许执行的原因。我们可以根据如下三个字段制定告警规则：

serviceaccount有权限的情况下：annotations.authorization.k8s.io/reasonannotations.authorization.k8s.io/decisionuserAgent: Go-http-client/1.1responseStatus.code：200
无权限的情况下：userAgent: Go-http-client/1.1responseStatus.code：403

因为tool模块需要借助高权限serviceaccount或token，因此，权限不足的情况下，api-server返回responseStatus.code: 403 的条目说明了api-server接受到了非预期请求，结合userAgent等信息便可输出可疑告警。

聚合 API 实际上是在 kube-apiserver 中运行的，在新 API 注册之前，它并不会工作。如果要添加新的 API，则需要创建一个APIService 对象，用来申请 Kubernetes 中新的 URL 路径。注册成功后，当有发送到此路径中的请求，则会被转发到已经注册的 APIService 上。

APIService 可以将客户端的请求转发到任意的 URL 上，这就有可能会导致 Client 发送请求时，所携带的一些认证信息可能会被发送给第三方。

通过日志审计监控responseStatus.code字段来进行判断是否有出现重定向的情况，通过检测如下字段：

responseObject.code:302responseObject.code:301

除了cdk这种常见的攻击手法，还有一些常见的异常行为需要我们关注，比如一般企业内，pod创建使用的容器均会从企业私有的镜像仓库中拉取，此时如果日志中出现了公共仓库的镜像，则可判断为异常，可关注以下字段

verb : createlevel:RequestResponseesponseObject.kind:Pod requestObject.spec.containers.image:镜像仓库地址

对于kubectl exec命令进行监控，可对如下字段进行监控，注：命令执行的后续无法通过日志审计来进一步监控，需结合运行时检测进一步分析

objectRef.subresource:execobjectRef.subresource:attachuserAgent

1、主要为k8s日志类型比较多，且每种类型的字段名，字段数量均不一致，导致es在存储数据时存在索引内字段类型不一致无法解析存储的问题。

解决方案为对于字段不一致的obj，选择为不做深层次解析。（或者使用hdfs等存储方式，查询时对字段进行解析

2、日志量过大，导致api-server磁盘读写io过高

持续优化audit.yaml中的日志规则，对于其中的node/status,pod/status,coordination.k8s.io/leases等不做日志记录。

本文从k8s日志审计的角度，分析当使用cdk等自动化攻击时，能够从日志中获取到的信息，并给出通过这些信息可监控字段的告警示例。因为这部分字段都比较固定，完全可以通过机器学习提升告警准确率。抛砖引玉，希望后续可以看到更多日志的分析防御角度。

当然，CDK作为开源工具，这些特征都可以做关键字替换。因此，笔者认为功夫应该用到平时，加强k8s的基线管控，比如避免出现高serviceaccount权限、通过准入策略限制使用的docker镜像，并部署容器运行时入侵检测平台。让安全能力覆盖每个环节，才能保证集群的安全稳定。

[1] https://github.com/cdk-team/CDK

[2] https://www.cdxy.me/?p=839

[3] https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

[4] https://discuss.kubernetes.io/t/security-advisory-cve-2022-3172-aggregated-api-server-can-cause-clients-to-be-redirected-ssrf/21322

[5]https://github.com/tencentyun/qcloud-documents/blob/master/product/%E5%AD%98%E5%82%A8%E4%B8%8ECDN/%E6%97%A5%E5%BF%97%E6%9C%8D%E5%8A%A1/%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/TKE%20%E5%AE%A1%E8%AE%A1%E6%97%A5%E5%BF%97%E5%88%86%E6%9E%90.md

[6] https://github.com/cdk-team/CDK/blob/main/pkg/exploit/k8s_backdoor_daemonset.go#LL35-L87C2

[7] https://github.com/cdk-team/CDK/blob/main/pkg/exploit/k8s_cronjob.go#LL34-L59C2

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！

• B站云原生混部技术实践

• B站基于Clickhouse的下一代日志体系建设实践
  

• B站埋点分析平台的构建之路