1. 项目概述：为什么我们需要Peirates这样的工具？

如果你负责运维或安全审计一个Kubernetes集群，那么“集群安全”这四个字的分量，你肯定深有体会。Kubernetes的复杂性不仅在于其强大的编排能力，更在于它构建了一个庞大、动态且相互关联的攻击面。一个配置不当的Service Account、一个权限过大的Role、一个暴露在公网的Dashboard，都可能成为攻击者进入集群、横向移动甚至控制整个基础设施的跳板。传统的网络层渗透测试工具，面对Kubernetes内部基于API Server、RBAC和Pod间通信的复杂模型时，常常显得力不从心。我们需要一种能“说Kubernetes语言”的工具，能够从集群内部视角，像攻击者一样思考、探测和利用。这就是Peirates诞生的背景。

Peirates不是一个简单的漏洞扫描器，它是一个功能全面的Kubernetes渗透测试平台。你可以把它理解为一个专门为Kubernetes环境打造的“瑞士军刀”或“渗透测试套件”。它的核心设计理念是：假设攻击者已经通过某种方式（例如，利用一个存在漏洞的Web应用，通过容器逃逸）在集群内的一个Pod中获得了立足点（即一个“已入侵的容器”）。从这个初始立足点出发，Peirates能帮助你系统性地进行权限提升、横向移动、信息收集和持久化，最终目标是获取集群管理员权限，从而全面评估集群的安全状况。对于安全工程师和红队成员来说，它是验证集群配置安全性的利器；对于运维和开发人员而言，它是理解自身集群安全风险、进行内部安全演练的绝佳指南。

2. Peirates核心功能与攻击路径拆解

理解Peirates，首先要理解它在Kubernetes环境中的典型攻击路径。这并非一个线性的步骤，而是一个循环、迭代的过程，Peirates的各个模块正是为这个过程中的每个环节服务的。

2.1 初始立足点与信息收集

攻击通常始于一个已被攻陷的Pod。Peirates启动后的第一件事，就是进行全面的环境感知和信息收集。这远不止是执行 uname -a 那么简单。

• 服务账户与令牌窃取 ：Peirates会自动检查Pod挂载的Service Account令牌（默认路径 /var/run/secrets/kubernetes.io/serviceaccount ）。这个令牌是Pod与Kubernetes API Server通信的凭证。获取它，就获得了以该Service Account身份行动的初始能力。
• 云元数据探测 ：如果集群部署在公有云（如AWS、GCP、Azure），Peirates会尝试访问云供应商的实例元数据服务（IMDS）。这常常是通往云平台更高权限的“后门”，可能获取到云主机的IAM角色凭证，从而将攻击面从Kubernetes集群扩展到整个云环境。
• 容器内敏感信息扫描 ：它会扫描容器内的环境变量、文件系统（如 /proc 目录、 /etc/passwd 、 /.ssh 等），寻找硬编码的密码、密钥、配置文件等。许多应用会错误地将生产环境凭证通过环境变量或配置文件带入容器。
• 网络发现与端口扫描 ：从容器内部，Peirates可以探测集群内网的其他服务。它能够枚举当前命名空间乃至整个集群的Service、Pod IP，并进行快速的端口扫描，寻找如数据库、缓存、内部API等可能存在弱点的服务。

注意 ：这一阶段的核心是“低调”。Peirates的信息收集动作设计得尽可能隐蔽，避免触发集群的安全告警（如异常API调用频率监控）。在实际渗透测试中，节奏控制非常重要。

2.2 权限提升与横向移动

获得初始凭证后，下一步是提升权限，扩大控制范围。

• RBAC权限分析 ：这是Peirates的强项。它会使用窃取到的令牌，向API Server查询当前Service Account所绑定的Role和ClusterRole，并详细列出其拥有的所有权限（Verbs），例如 get pods , list secrets , create pods 等。一个常见的提权路径是：某个Service Account拥有 get secrets 权限，攻击者就可以列出并窃取其他包含高权限凭证的Secret。
• 特权容器与节点渗透 ：Peirates会检查当前容器是否以特权模式运行，或者是否挂载了敏感的主机路径（如 / , /var/run/docker.sock ）。如果发现此类配置，它会提供利用路径，例如在特权容器中直接访问主机文件系统、安装软件，甚至通过挂载的Docker Socket在宿主机上运行容器，实现节点级别的突破。
• Pod创建与控制 ：如果当前身份拥有 create pod 权限，攻击者可以创建一个新的Pod，并将其调度到目标节点。这个新Pod可以配置为特权模式、挂载主机根文件系统，从而完全控制该节点。这是从容器权限到节点权限的经典跨越。
• 窃取与滥用高权限Secret ：通过遍历Secrets（尤其是 kube-system 命名空间下的），寻找如 cluster-admin 的Service Account令牌、云平台凭证等。一旦获得集群管理员的令牌，整个集群就门户大开了。

2.3 持久化与后渗透

在获得高权限后，攻击者需要考虑如何维持访问，即使最初的漏洞被修复。

• 创建后门Service Account ：Peirates可以帮助攻击者创建一个新的Service Account，并为其绑定高权限的ClusterRole（如 cluster-admin ），然后将对应的Secret令牌提取出来。这样，攻击者就拥有了一个独立的、隐蔽的管理员账户。
• 部署恶意DaemonSet或Deployment ：利用 create daemonset 权限，可以在集群所有节点上部署一个持久化的后门Pod。即使某个Pod被清理，DaemonSet控制器也会立即重新创建它，极难根除。
• 配置恶意Webhook ：如果拥有修改集群级别资源（如ValidatingWebhookConfiguration）的权限，可以注入恶意的Admission Webhook，拦截所有Pod创建请求，自动在其中注入后门容器或侧车容器，实现“感染”所有新工作负载。

3. Peirates实战部署与核心模块详解

了解了攻击路径，我们来看看如何实际使用Peirates。它通常以容器镜像的形式分发，部署到目标集群的一个测试Pod中。

3.1 环境准备与工具部署

首先，你需要一个具有足够权限（至少能创建Pod）的Kubernetes环境来运行Peirates。 强烈建议在你自己完全控制的测试集群（如minikube、kind或一个隔离的沙箱集群）中进行演练，切勿在生产环境直接测试！

一个典型的部署YAML如下：

apiVersion: v1
kind: Pod
metadata:
  name: peirates-pentest-pod
  namespace: default # 可以指定特定namespace
spec:
  serviceAccountName: default # 这里使用默认的Service Account，实际测试中可替换为你想测试的SA
  containers:
  - name: peirates
    image: inquisite/peirates:latest # 官方镜像
    command: ["/bin/sleep"]
    args: ["infinity"] # 让Pod保持运行，以便我们exec进入
    securityContext:
      runAsUser: 0 # 以root用户运行，方便测试特权操作（非必需）
  automountServiceAccountToken: true # 确保挂载SA令牌

应用这个配置后，通过 kubectl exec -it peirates-pentest-pod -- /bin/bash 进入容器。在容器内，你可以从GitHub下载或直接运行Peirates。更简单的方式是，其镜像通常已经包含了可执行文件，你可以直接找到并运行它。

3.2 核心交互模块实操解析

Peirates采用交互式命令行界面，模块清晰。启动后，你会看到一个主菜单。

1. 信息收集模块 输入对应编号，例如选择 [1] Gather Information ，它会展示子菜单：

• Get current service account token : 立即显示当前Pod使用的SA令牌。
• List secrets in this namespace : 枚举当前命名空间的Secret。这里是你寻找“宝藏”的第一站。
• Get all pods in this namespace/cluster : 了解周围环境。
• Check for cloud metadata API : 自动探测并尝试访问AWS、GCP、Azure的元数据端点。 实操心得 ：在公有云环境中，这一步的收获常常超出预期。我曾在一个配置不当的集群中，通过此功能直接获取到了拥有S3完全访问权限的IAM角色临时凭证。

2. 权限提升模块 选择 [2] Attempt Privilege Escalation ：

• Check current RBAC permissions : 详细分析当前令牌的API权限。输出会告诉你，你是否能 get 、 list 、 create 或 delete 哪些资源（Pods, Secrets, Roles等）。这是决策下一步行动的关键依据。
• Attempt to list all secrets in the cluster : 如果权限允许，这将尝试列出所有命名空间的Secret。一个拥有 list secrets 权限的ClusterRole绑定，是攻击者的黄金门票。
• Check for privileged pod creation : 尝试利用 create pod 权限，生成一个特权Pod的YAML模板，供你进一步利用。

3. 横向移动模块 选择 [3] Lateral Movement ：

• Run command in another pod : 如果你窃取到了某个高权限SA的令牌，可以在这里切换上下文，用新令牌对其他Pod执行命令。
• Deploy a pod to a specific node : 这是关键功能。你需要提供目标节点名、要执行的命令（如反弹Shell）以及（可选的）一个更高权限的SA。Peirates会生成并部署一个Pod到该节点，如果该Pod是特权或挂载了主机路径，你就能控制该节点。

4. 持久化模块 选择 [4] Establish Persistence ：

• Create a new service account with high privileges : 交互式引导你创建一个新SA并绑定admin角色。你需要提供命名空间和角色名。 注意事项 ：创建的资源（SA, RoleBinding）会留下明显的审计日志。在真实的红队评估中，需要权衡隐蔽性和必要性，或通过清理日志等方式进行反制。
• Create a privileged pod in the kube-system namespace : 在 kube-system 命名空间部署一个Pod，由于其特殊性，通常更不容易被常规监控发现。

3.3 一次完整的攻击模拟流程

假设我们进入了一个默认Service Account权限的Pod。

1. 启动与信息收集 ：运行Peirates，先执行 [1] Gather Information 下的所有检查。发现当前SA令牌，发现它只有默认的、受限的权限。
2. 检查RBAC ：进入 [2] Attempt Privilege Escalation -> Check current RBAC permissions 。输出显示，我们只有对自己所在Pod的 get 权限，几乎没有其他权限。这是一条死胡同吗？不一定。
3. 扫描Secrets ：回到 [1] ，选择 List secrets in this namespace 。意外发现同一个命名空间下，存在一个名为 ci-cd-token 的Secret。
4. 窃取与切换凭证 ：利用 [1] 中的功能（或手动 kubectl get secret ）查看该Secret内容。发现里面包含了一个Service Account的令牌。我们将这个令牌内容复制出来。
5. 权限跃迁 ：在Peirates主菜单，通常有切换当前活动令牌的选项（如 Use a different service account token ）。我们粘贴刚窃取的 ci-cd-token 。
6. 重新评估权限 ：再次执行 Check current RBAC permissions 。惊喜地发现，这个CI/CD用的SA拥有 get 、 list 、 watch 所有命名空间 secrets 和 pods 的权限。
7. 扩大战果 ：使用 [2] 中的 Attempt to list all secrets in the cluster 。在 kube-system 命名空间下，找到了 cluster-admin 的SA令牌Secret。
8. 夺取集群控制权 ：窃取 cluster-admin 的令牌，并在Peirates中切换为它。此时，你的权限已等同于Kubernetes集群管理员。
9. 持久化 ：进入 [4] Establish Persistence ，创建一个属于你自己的、绑定 cluster-admin 角色的后门Service Account，并保存好其令牌。这样，即使最初的入侵点被修复，你仍保有访问权限。
10. 清理与渗透测试报告 ：在授权的渗透测试中，最后一步是清理你创建的所有后门资源（Pod, ServiceAccount, RoleBinding等），并基于整个过程中发现的薄弱环节（如过宽的RBAC、敏感Secret存放不当、特权容器等）撰写详细的安全报告。

4. 防御视角：如何让你的集群对Peirates“免疫”

作为防御方，了解攻击工具是为了更好地防御。针对Peirates所利用的每一处弱点，我们都可以采取相应的加固措施。

4.1 最小权限原则与RBAC加固

这是防御的基石，能有效阻断Peirates的权限提升路径。

• 为Pod使用专用的、最小权限的Service Account ：永远不要给Pod使用 default 这个SA。为每个部署创建独立的SA。
• 精确控制RBAC ：使用Role和RoleBinding，而非ClusterRole和ClusterRoleBinding，除非绝对必要。遵循最小权限原则，仔细审核每个SA所需的API动词（verbs）。例如，一个只读的监控应用，只需要 get 和 list Pods的权限，绝不需要 create 或 delete 。
• 定期审计RBAC配置 ：使用 kubectl auth can-i --list 命令检查某个SA的权限。或者使用像 kubeaudit 、 kubectl-who-can 这样的工具进行自动化审计。一个常见的检查清单是：查找所有拥有 * （通配符）动词的规则，以及所有绑定到 cluster-admin 、 admin 、 edit 等宽泛内置角色的SA。

4.2 敏感信息管理与安全配置

• 保护Secret ：将Secret视为最高机密。避免在非必要命名空间存放高权限Secret（如 cluster-admin 令牌）。考虑使用外部Secret管理工具（如HashiCorp Vault、AWS Secrets Manager），并通过CSI驱动动态注入，而不是将Secret以静态文件形式存储在etcd中。
• 禁用自动挂载SA令牌 ：对于不需要访问Kubernetes API的Pod，在Pod Spec中设置 automountServiceAccountToken: false 。这能从根本上防止令牌被窃取。
• 限制云元数据访问 ：在公有云上，为Worker节点配置IMDSv2（需要令牌的元数据服务版本），并为节点实例配置最小权限的IAM角色。使用网络策略或安全组规则，限制Pod对云元数据服务端点（如 169.254.169.254 ）的访问。
• 禁止特权容器与危险挂载 ：通过Pod安全标准（Pod Security Standards）或准入控制器（如Pod Security Admission, OPA Gatekeeper）强制执行策略：禁止运行特权容器（ privileged: true ），禁止挂载主机敏感目录（如 / , /var/run/docker.sock ）。

4.3 网络隔离与运行时监控

• 实施网络策略 ：使用Calico、Cilium等CNI插件提供的NetworkPolicy功能，实现Pod之间的网络隔离。遵循“默认拒绝”原则，只允许必要的Pod间通信。这能极大限制攻击者在攻破一个Pod后的横向移动能力。
• 启用运行时安全监控 ：部署Falco、Aqua Security或Sysdig等运行时安全工具。它们可以检测异常行为，例如：容器内执行 kubectl 命令、访问Service Account令牌文件、创建特权Pod、访问云元数据API等。这些正是Peirates的典型行为特征。
• 审计日志分析 ：确保启用并集中收集Kubernetes API Server的审计日志。监控异常模式的API调用，例如：某个低权限SA突然尝试 list secrets ，或者来自非常规Pod的频繁RBAC查询请求。使用ELK栈或SIEM工具对审计日志进行实时分析。

4.4 定期进行安全评估与漏洞扫描

• 主动使用Peirates进行内部红队演练 ：在测试环境中，定期以攻击者的视角，使用Peirates对你的集群配置进行攻击模拟。这能最直观地暴露现有安全策略的盲点。
• 集成静态配置扫描 ：在CI/CD流水线中集成kube-bench、kube-hunter、Checkov等工具，对Kubernetes清单文件和集群配置进行静态安全检查，提前发现不符合安全基准的配置。
• 进行镜像漏洞扫描 ：使用Trivy、Grype等工具扫描容器镜像中的已知漏洞，防止攻击者通过应用漏洞获得初始立足点。

将Peirates这样的攻击工具纳入你的防御武器库，从攻击者的角度思考，是构建真正有韧性的Kubernetes安全体系不可或缺的一环。安全是一个持续的过程，而非一劳永逸的状态。通过理解攻击链，并针对性地部署层层防御，你才能让你的Kubernetes集群在面对真实威胁时，拥有更强的抵御能力。