本文我们将来解析一些K8s集群入侵排查技巧，帮助大家快速找到攻击者的入侵痕迹，还原攻击路径，更高效地进行问题排查。

在K8s应急场景中，我们可以根据K8s的不同层级，将安全事件分为三类，针对不同的阶段选择不同的应对方式。

当Pod遭受入侵时，我们需要进入Pod里面进行入侵排查。 

最直接的方法就是进入有问题的 Pod 内执行命令，通常可以使用 kubectl exec 命令在指定的 Pod 容器中操作。

kubectl exec -it nginx-5c47845dd7-k6dp9 -- bash

这种方法虽然简单易用，但受限于运行中的应用 Pod 环境，往往缺少排查问题所需的命令或工具，无法满足深入分析的需求，导致效率低下。

K8s 提供了kubectl debug命令，通过临时容器共享命名空间的方式分析业务容器，而且可以从临时容器访问业务容器的文件系统，根文件系统位于/proc/1/root目录下。

kubectl debug -it nginx-5c47845dd7-k6dp9 --image=busybox:latest --target=nginx

这种方式可以更加通用，可以满足深入分析和排查问题的需求，灵活高效，不会影响业务容器应用。

虽然可以使用 kubectl exec 命令进入Pod内部查看日志，K8s使用 kubectl logs 命令查看Pod日志。

kubectl logs web-86cd4d65b9-pwwlm

当Node节点遭受入侵时，我们需要安全排查节点服务器的安全状态，以确认入侵的影响。

kubectl debug node是Kubernetes提供的强大节点调试工具，它让集群管理员能够在无需直接SSH访问的情况下深入检查节点状态，特别适用于无法通过SSH直接访问节点的场景。

当需要调试某个节点时，可以使用kubectl debug node 命令，这个命令会在目标节点上创建一个临时容器，访问节点服务器，并提供一个交互式的 Shell 环境。临时容器运行在主机的命名空间中，节点根文件系统挂载在 /host上。 

kubectl debug -it node/node  --image=busybox:latest

容器标准输出: /var/lib/docker/containers/<Container-ID>/-json.log容器日志: /var/log/containers/*.logkubelet日志：  journalctl  -u kubelet

K8s Audit 记录了集群中所有API Server的请求，当K8s集群遭受入侵时，K8s Audit 拥有独特的视角，可以帮助我们看清集群层面的攻击行为，重点关注 sourceIPS、user、userAgent、verb等字段，发现K8s集群层面的攻击行为，定位问题的根源。

攻击特征：未认证用户尝试使用集群管理员权限执行操作。

user: {"username":"system:unsecured", "groups":["system:masters","system:authenticated"]}

攻击特征：user.username 可能包含服务账号，userAgent字段包含curl。

"user.username"="system:serviceaccount:test:bypass" userAgent="curl/7.68.0"

攻击特征：sourceIPs不在信任范围，userAgent包含kubectl信息。

"sourceIPs{}"="192.168.44.133" userAgent="kubectl/v1.28.2 (linux/amd64) kubernetes/89a4ea3"

攻击特征：攻击者成功创建特权Pod。

verb=create "responseStatus.code"=201 "requestObject.spec.containers{}.securityContext.privileged"=true

攻击特征：攻击者将宿主机的根目录 / 以 hostPath 的方式挂载到容器。

verb=create  "responseStatus.code"=201 "responseObject.spec.volumes{}.hostPath.path"="/"

攻击特征：攻击者成功创建 CronJob。

verb=create "responseStatus.code"=201 "objectRef.resource"=cronjobs