Kubernetes Pod 权限提升检测指南基于 Anthropic-Cybersecurity-Skills 的准入控制、运行时监控与审计日志三层防御【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills在 Kubernetes 环境中权限提升Privilege Escalation通常意味着 Pod 或容器获得了超出其预期范围的权限——以 root 运行、启用 privileged 模式、挂载宿主文件系统、持有危险 Linux capabilities甚至利用内核漏洞逃逸到宿主机。本文基于开源仓库 Anthropic-Cybersecurity-Skills 中的detecting-privilege-escalation-in-kubernetes-pods技能包系统讲解如何以「准入控制预防— 运行时监控检测— 审计日志调查」三层防线组合检测与阻断此类攻击并附上可直接落地的清单assets/template.md、配置模板与仓库内置的扫描脚本用法。读完本文你将能够为生产命名空间强制受限级 Pod 安全策略、编写 OPA Gatekeeper 约束拦截危险配置、部署 Falco 运行时规则捕获越权行为并利用 Kubernetes 审计日志与自带 Python 脚本完成事件调查。一、理解 Pod 权限提升的攻击面Kubernetes 中的权限提升本质上是「容器获取超出其沙箱隔离范围权限」的过程。常见的实现路径包括privileged: true直接获得宿主机全部能力、hostPID/hostNetwork/hostIPC共享宿主命名空间、hostPath卷读写宿主文件系统、危险的 Linux capabilities如SYS_ADMIN实现容器逃逸以及runAsUser: 0以 root 运行。技能主文档SKILL.md给出的威胁向量与检测手段对应关系如下向量风险检测方法privileged: true完全宿主访问权限准入控制 审计hostPID: true访问宿主进程准入控制hostNetwork: true访问宿主网络栈准入控制hostPath 卷读写宿主文件系统准入控制SYS_ADMIN capability近似特权访问准入 运行时allowPrivilegeEscalation: truesetuid/setgid 提权利用准入控制runAsUser: 0容器内 root准入控制automountServiceAccountToken令牌窃取用于 API 访问准入控制可写 /proc 或 /sys内核参数操纵运行时监控从仓库附带的 references/api-reference.md 可看到更细粒度的安全上下文securityContext风险定级privileged: true与hostPID: true为 CRITICALallowPrivilegeEscalation、runAsUser: 0、hostNetwork: true为 HIGH。这些检查项全部落在 Pod 的spec.securityContext与spec.containers[].securityContext上构成了后续准入策略与扫描脚本的判定基础。二、预防与检测清单落地前的自检基线assets/template.md 是技能包的落地清单Checklist将安全工作拆分为「预防控制」与「检测控制」两组可直接作为安全评审、上线前检查或 SOC 监控覆盖度评估的核对表。预防控制Prevention Controls生产命名空间启用restricted级别的 Pod Security AdmissionOPA Gatekeeper 约束阻止特权容器通过变更 Webhook 强制默认 security context在准入阶段阻断危险 capabilities检测控制Detection Controls部署针对权限提升模式的 Falco 规则启用 Kubernetes 审计日志为 CRITICAL 级发现配置告警定期执行集群扫描清单的意义在于将「检测能力」本身视为可审计、可验证的资产预防层准入控制与检测层运行时监控、日志、扫描缺一不可。后文的三个章节分别对应这两组控制的落地方法。三、必须阻断的危险配置清单template.md中最核心的可执行资产是一张将「危险配置 → 风险等级 → 对应 Pod 安全标准PSA配置文件」直接关联的表它是编写准入策略与扫描规则时的权威依据配置风险等级PSA Profileprivileged: trueCRITICALBaseline 阻断hostPID: trueCRITICALBaseline 阻断hostNetwork: trueHIGHBaseline 阻断allowPrivilegeEscalation: trueHIGHRestricted 阻断runAsUser: 0HIGHRestricted 阻断capabilities.add: SYS_ADMINCRITICALRestricted 阻断hostPath 卷HIGHRestricted 阻断automountServiceAccountToken: trueMEDIUM手工处置这张表的工程价值在于「按 PSA 配置档位分级封堵」Baseline档即阻断privileged、hostPID、hostNetwork三类高危宿主共享配置Restricted档在此基础上进一步阻断allowPrivilegeEscalation、root 运行与危险 capabilities而automountServiceAccountToken这类中危项未被任何标准档强制约束需要靠组织策略手工处置。该定级逻辑在仓库脚本 scripts/process.py 中得到印证——其DANGEROUS_CAPS集合包含SYS_ADMIN、SYS_PTRACE、SYS_MODULE、DAC_OVERRIDE、NET_ADMIN、NET_RAW、SYS_RAWIO、SYS_BOOT且对privileged判定为 CRITICAL、对hostNetwork/runAsUser: 0判定为 HIGH与清单的风险定级完全一致。四、第一层防线准入控制Prevention4.1 内置 Pod Security AdmissionPSAKubernetes v1.25 内置的 Pod Security AdmissionPSA是最低成本的准入控制手段。SKILL.md 的前置条件即要求集群 v1.25。通过给命名空间打标签即可启用三个档位privileged/baseline/restricted的强制执行# Enforce restricted policy on namespace apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted三个标签分别对应三种行为enforce直接拒绝违规 Pod 创建、audit将违规记录写入审计日志而不阻断、warn仅向用户返回警告。生产命名空间建议三者全部设置为restricted。三个档位的约束差异源自 references/standards.md配置档级别关键限制Privileged无限制无任何限制Baseline最小限制禁止 privileged、hostPID/hostNetworkRestricted强限制非 root、丢弃全部 capabilities、禁止提权4.2 OPA Gatekeeper 自定义约束PSA 只能覆盖内置检查项对于「阻断指定危险 capabilities」等细粒度需求需要 OPA Gatekeeper 或 Kyverno 这类可编程准入控制器。仓库给出一个完整的ConstraintTemplate示例用 Rego 语言同时拦截危险 capabilities、privileged 模式、allowPrivilegeEscalation、hostPID 与 hostNetwork# Block dangerous capabilities apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sdangerouspriv spec: crd: spec: names: kind: K8sDangerousPriv targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sdangerouspriv dangerous_caps : {SYS_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_OVERRIDE, NET_ADMIN, NET_RAW} violation[{msg: msg}] { container : input.review.object.spec.containers[_] cap : container.securityContext.capabilities.add[_] dangerous_caps[cap] msg : sprintf(Container %v adds dangerous capability: %v, [container.name, cap]) } violation[{msg: msg}] { container : input.review.object.spec.containers[_] container.securityContext.privileged true msg : sprintf(Container %v runs in privileged mode, [container.name]) } violation[{msg: msg}] { container : input.review.object.spec.containers[_] container.securityContext.allowPrivilegeEscalation true msg : sprintf(Container %v allows privilege escalation, [container.name]) } violation[{msg: msg}] { input.review.object.spec.hostPID true msg : Pod uses host PID namespace } violation[{msg: msg}] { input.review.object.spec.hostNetwork true msg : Pod uses host network }注意 Rego 中dangerous_caps集合与template.md清单一致SYS_ADMIN为 CRITICAL 级实际生产中建议将该集合与脚本侧DANGEROUS_CAPS保持同步避免准入规则与扫描规则出现盲区差异。部署约束后应使用「创建非合规 Pod」的方式进行验证——这也是 references/workflows.md 中 Phase 2 的明确步骤先施加标签/约束再确认违规 Pod 被拒绝。五、第二层防线Falco 运行时监控Detection准入控制只能拦截「创建时」的恶意配置无法发现运行时权限变更如进程通过 setuid 提权、调用capset获得能力。因此需要 Falco 这类基于 syscall 的运行时安全工具。SKILL.md 提供了四条约规则可保存为/etc/falco/rules.d/privesc-detection.yaml# /etc/falco/rules.d/privesc-detection.yaml - rule: Setuid Binary Execution in Container desc: Detect execution of setuid/setgid binaries in a container condition: spawned_process and container and (proc.name in (su, sudo, newgrp, chsh, passwd) or proc.is_exe_upper_layertrue) output: Setuid/setgid binary executed in container (user%user.name container%container.name image%container.image.repository command%proc.cmdline parent%proc.pname) priority: WARNING tags: [container, privilege-escalation, T1548] - rule: Capability Gained in Container desc: Detect when a process gains elevated capabilities condition: evt.type capset and container and evt.arg.cap ! output: Process gained capabilities in container (container%container.name image%container.image.repository capabilities%evt.arg.cap command%proc.cmdline) priority: WARNING tags: [container, privilege-escalation, T1548.001] - rule: Container with Dangerous Capabilities Started desc: Detect container launched with dangerous capabilities condition: container_started and container and (container.image.repository ! registry.k8s.io/pause) and (container.cap_effective contains SYS_ADMIN or container.cap_effective contains SYS_PTRACE or container.cap_effective contains SYS_MODULE) output: Container with dangerous capabilities (container%container.name image%container.image.repository caps%container.cap_effective) priority: CRITICAL tags: [container, privilege-escalation, T1068] - rule: Write to /etc/passwd in Container desc: Detect writes to /etc/passwd inside container condition: open_write and container and fd.name /etc/passwd output: Write to /etc/passwd in container (container%container.name image%container.image.repository command%proc.cmdline user%user.name) priority: CRITICAL tags: [container, privilege-escalation, T1136]四条规则分别覆盖三类运行时提权信号setuid/setgid 提权T1548su、sudo、newgrp、chsh、passwd等典型 setuid 二进制在容器内被执行或执行了来自镜像上层proc.is_exe_upper_layertrue的可疑二进制运行时能力提升T1548.001通过capsetsyscall 为进程追加 capabilities危险能力容器的启动T1068启动时有效能力集cap_effective包含SYS_ADMIN/SYS_PTRACE/SYS_MODULE规则将 pause 容器排除以减少误报账户创建信号T1136容器内对/etc/passwd的写操作通常是创建后门账户的前奏。优先级设计也值得借鉴危险能力容器启动为 CRITICAL写/etc/passwd为 CRITICAL其余两条为 WARNING——对应 assets/template.md 中「为 CRITICAL 发现配置告警」的要求可直接将 CRITICAL 级别规则接入 PagerDuty/SIEM 告警通道。六、第三层防线Kubernetes 审计日志与调查6.1 审计策略配置准入与运行时监控之外审计日志负责「事后可追溯」。SKILL.md 给出的audit-policy.yaml聚焦三类高价值事件# audit-policy.yaml - Capture privilege escalation events apiVersion: audit.k8s.io/v1 kind: Policy rules: # Log pod creation with security context details - level: RequestResponse resources: - group: resources: [pods] verbs: [create, update, patch] # Log privilege escalation attempts - level: RequestResponse resources: - group: rbac.authorization.k8s.io resources: [clusterroles, clusterrolebindings, roles, rolebindings] verbs: [create, update, patch, bind, escalate] # Log service account token requests - level: Metadata resources: - group: resources: [serviceaccounts/token] verbs: [create]策略设计要点Pod 创建/变更记录使用RequestResponse级别以便审计日志中保留完整的requestObject内含 securityContext供事后检查 privileged、capabilities 等字段RBAC 绑定事件覆盖bind与escalate动词直接捕获权限提升动作serviceaccounts/token使用Metadata级别记录令牌请求而不落敏感 body。6.2 审计日志查询审计日志通常通过 kube-apiserver 的标准输出采集。仓库提供了两条基于jq的查询命令# Find pods created with privileged security context kubectl logs -n kube-system kube-apiserver-* | \ jq select(.verb create and .objectRef.resource pods) | select(.requestObject.spec.containers[].securityContext.privileged true) # Find RBAC escalation attempts kubectl logs -n kube-system kube-apiserver-* | \ jq select(.objectRef.resource clusterrolebindings and .verb create)在生产环境中这些 JSON 行应统一转发至 SIEM如 Elasticsearch/Splunk而非直接kubectl logs以便做时序关联与长期留存。6.3 调查 Playbook收到告警后的调查流程SKILL.md 与 references/workflows.md 的 Phase 4 呼应可拆解为四步命令# 1. Check pod security context kubectl get pod pod-name -n ns -o jsonpath{.spec.containers[*].securityContext} # 2. Check effective capabilities kubectl exec pod-name -n ns -- cat /proc/1/status | grep -i cap # 3. List pods running as root kubectl get pods --all-namespaces -o json | \ jq .items[] | select(.spec.containers[].securityContext.runAsUser 0 or .spec.containers[].securityContext.privileged true) | {name: .metadata.name, ns: .metadata.namespace} # 4. Check for hostPath volumes kubectl get pods --all-namespaces -o json | \ jq .items[] | select(.spec.volumes[]?.hostPath ! null) | {name: .metadata.name, ns: .metadata.namespace, paths: [.spec.volumes[].hostPath.path]}第 2 步通过读取容器 PID 1 的/proc/1/status中CapEff/CapBnd行可验证容器运行时的实际有效能力集用于与 Falcocontainer.cap_effective告警交叉印证。确认受害 Pod 后workflow 文档给出的响应顺序为识别受损 Pod → 检查安全上下文 → 审查进程列表与能力 → 用网络策略隔离 → 采集取证数据 → 删除受损 Pod。七、集群主动扫描仓库自带脚本的工程化实践该技能包在 scripts/ 目录提供了两个可直接运行的 Python 扫描器将上述检查项固化为自动化工具正好对应清单中「定期集群扫描」这一检测控制项。agent.pyAPI 参考见 references/api-reference.md调用kubectl get pods -o json拉取集群 Pod对每个 Pod 执行安全审计输出 JSON 报告。其DANGEROUS_CAPABILITIES集合为{SYS_ADMIN, SYS_PTRACE, SYS_MODULE, NET_ADMIN, NET_RAW, DAC_READ_SEARCH, SYS_RAWIO}并额外检查了hostIPCMEDIUM、可写根文件系统readOnlyRootFilesystem缺失MEDIUM、容器运行时 Socket 挂载/var/run/docker.sock、/run/containerd/containerd.sockCRITICAL。使用方式python agent.py --namespace default python agent.py --json-file pods.jsonprocess.py功能更完整的命令行扫描器支持按严重级别排序输出报告、JSON 输出以及与 CI 集成的失败阈值控制# 全集群扫描 python process.py # 指定命名空间扫描 python process.py --namespace production # JSON 输出 python process.py --json # CI 集成存在 HIGH 及以上发现即退出码非 0 python process.py --fail-on high--fail-on的阈值映射为critical→ 仅 CRITICAL 阻塞high→ CRITICALHIGH 阻塞medium→ 三级全部阻塞。这使其天然适合接入 GitOps 流水线作为准入前的补充校验层。脚本的检查项覆盖与template.md清单、PSA 限制保持同构privileged/hostPID判 CRITICALhostNetwork/hostPath/runAsUser: 0判 HIGHallowPrivilegeEscalation判 MEDIUM危险 capability 判 CRITICAL——可作为「策略声明清单与实现脚本一致性」的活文档。八、框架对齐为什么这些检测值得做从威胁建模角度该技能包在 references/standards.md 中将检测能力对齐到多个权威框架便于安全团队纳入合规与覆盖度评估技术MITRE ATTCK ID描述逃逸到宿主T1611通过权限提升实现容器逃逸利用漏洞提权T1068从容器利用内核漏洞滥用提权控制T1548setuid/setgid 二进制利用有效账户T1078服务账户令牌窃取创建账户T1136容器内修改 /etc/passwd此外还关联了 CIS Kubernetes Benchmark v1.8 的 5.2.1-5.2.9Pod 安全标准与 5.7.3为 Pod 应用安全上下文、NIST SP 800-190 第 4.3 节容器运行时漏洞与第 5.4 节权限提升运行时监控。技能元数据SKILL.md front-matter还声明了 D3FEND 技术Executable Denylisting、Execution Isolation 等与 NIST CSF 控制项PR.PS-01、PR.IR-01、ID.AM-08、DE.CM-01说明该能力同时覆盖「识别—保护—检测」三类安全功能。九、加固最佳实践清单综合 SKILL.md 的八条最佳实践最终落地建议如下生产命名空间启用 Pod Security Admissionrestricted档并用warn/audit先行灰度丢弃 ALL capabilities仅按需加回capabilities.drop: [ALL] 最小白名单所有容器设置allowPrivilegeEscalation: false非 root 运行runAsNonRoot: true、runAsUser: 0除非确需 API 访问关闭automountServiceAccountToken对应清单中的 MEDIUM 手工项Falco 监控运行时提权尝试部署第五节四条规则CRITICAL 接入告警用 Kubernetes 审计日志监控 RBAC 变更关注bind/escalate动词使用 seccomp 配置限制 syscall进一步收窄内核攻击面。十、总结本技能包给出了一个完整的「检测权限提升」闭环template.md提供可勾选的风险清单与配置定级表PSA/OPA Gatekeeper 负责创建期阻断Falco 负责运行期捕获审计日志与 scripts/ 内置扫描器负责追溯与主动巡检最后通过 MITRE/CIS/NIST 框架完成覆盖度对齐。四层手段共享同一套判定语义privileged、hostPID、危险 capabilities、root 用户等在工程实践中应保持清单、准入规则、Falco 规则与扫描脚本之间的配置同步避免出现「准入拦截了但扫描器查不到」或反之的覆盖盲区。相关文件速览主文档SKILL.md检查清单assets/template.mdAPI 参考references/api-reference.md标准对齐references/standards.md工作流references/workflows.md扫描脚本scripts/agent.py、scripts/process.py【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考