Marico's space
最近折腾 Kubernetes 安全这块，踩了几个坑，最大的感受是：真正让集群失守的，往往不是某个组件突然爆了个高危漏洞，而是凭据泄露之后，攻击者沿着权限链一路横向移动。于是这篇把 OWASP Kubernetes Top 10 里的风险拆开讲，重点说清楚凭据为什么值得单独拎出来看。
Kubernetes 已经是现代基础设施的重要底座。根据云原生计算基金会（CNCF）最新的年度云原生调查，82% 的容器用户已经在生产环境中运行 Kubernetes。对大多数希望容器化部署应用的 DevOps 团队来说，Kubernetes 通常是首选方案。
Kubernetes（K8s）的优势很多，但配置和使用不当也会带来不少坑，这正是 OWASP（开放 Web 应用安全项目）专门发布 Kubernetes Top 10 的原因。
Kubernetes 的安全风险横跨工作负载、身份和基础设施。一个被攻陷的容器可能暴露服务账号凭据，而该服务账号又可能拥有访问其他系统的权限，并在那里找到更多凭据。很多时候，凭据能够访问的范围远远超出最初的集群。
GitGuardian 最近的几项调查，已经把这些攻击路径展示得很清楚。研究人员发现，泄露的凭据可以访问 44 个活跃 Kubernetes 集群。GhostAction 供应链攻击通过 GitHub Actions 窃取了大量 K8s 凭据。另一次调查则发现，一个公开仓库中包含 CISA 相关的基础设施配置和有效凭据。
面对持续针对 Kubernetes 的威胁，现在是重新审视 OWASP Kubernetes Top 10 的时候了。这十类风险覆盖了攻击者进入 Kubernetes 环境、扩大权限以及触达关联基础设施时最常利用的弱点。
OWASP Kubernetes Top 10 按照优先级梳理了当前最值得处理的 Kubernetes 环境风险。这些并非停留在理论层面的假设，而是社区正在持续发现和修复的真实问题，主要涉及不安全配置、薄弱访问控制，以及敏感资源保护失效。
这些风险经常相互叠加。一个被攻陷的工作负载可能暴露权限过大的凭据，而这些权限又能让攻击者访问更多工作负载或云资源。
特权容器、过度授予的 Linux Capabilities（系统能力）以及危险的主机目录挂载，都可能让工作负载获得超出实际需要的访问权限。攻击者一旦控制这些工作负载，就可能读取敏感文件，甚至接触底层基础设施。
基于角色的访问控制（RBAC）决定了用户和服务账号在 Kubernetes 中可以访问什么。权限给得过大，就会扩大被攻陷身份可用的操作能力，包括读取 Kubernetes Secrets（密钥对象）或修改工作负载。
K03 关注 Kubernetes 密钥管理失败。应用需要 API（应用程序接口）密钥、密码和令牌等凭据完成连接，而这些凭据可能以明文形式出现在代码仓库、容器镜像和应用配置中。长期有效凭据以及其他薄弱认证机制，会显著提升它们对攻击者的价值。
准入策略可以在工作负载进入集群时统一执行安全要求。理想状态下，每项操作都应该符合策略，但如果执行标准不统一，危险配置和过高权限仍然可能进入生产环境。
Kubernetes NetworkPolicy（网络策略）用于按照配置限制工作负载之间的通信。网络分段过弱或缺失时，攻击者在攻陷一个应用后，可以在服务之间横向移动。如果有效凭据也能被利用，这种风险尤其危险。理想状态是，即便攻击者拿到了访问权限，影响范围也应尽可能小。
集群中越多组件能够从公网访问，攻击者获得的优势就越大。暴露 API Server（API 服务端）和管理接口，会增加未授权访问的机会。攻击者既可能利用存在漏洞的组件，也可能使用窃取的凭据与集群管理服务进行交互。
Kubernetes 有很多种配错方式，也有不少正确配置的方法。这也是部署开源项目时普遍面临的挑战：不仅要一次配对，还要持续更新。组件漏洞可能让攻击者进入基础设施，或者获得进一步提升权限的机会。
Kubernetes 工作负载经常使用云身份和云凭据，这让集群具备很强的业务能力，也带来了明显风险。如果云权限过大，攻击者控制工作负载后，就可能访问集群之外的资源。
攻击者攻陷一个系统后，未必需要利用漏洞强行突破，也可能直接使用有效身份登录。薄弱的认证控制，以及保护不当的服务账号令牌，都可能让攻击者冒充受信任身份，获得通常设置得过于宽泛的权限。窃取的凭据甚至可能带来与合法工作负载或用户完全相同的访问能力。
如果攻击真的发生了，你如何知道，又如何证明？安全团队需要看清认证事件、API 请求以及敏感资源变更。没有足够的监控，团队就很难发现和证明凭据滥用或未授权活动。审计人员还需要知道团队何时发现风险，以及之后采取了什么措施。
针对 K03——Secrets Management Failures，OWASP 总结了六种最常见的凭据暴露方式。
LIST 或 WATCH 权限，就可能批量读取这些密钥。过于宽泛的 RBAC 权限，由此直接变成一条凭据暴露路径。stdout 或 stderr，尤其是在记录配置或环境状态时。这些密钥随后可能进入 Splunk 或 Elasticsearch 等集中式日志系统，并长期保留。这些问题可能来自很多入口。开发人员可能在测试时把凭据写进 Dockerfile，自动化系统可能拿到权限极强的服务账号令牌，应用也可能在排查故障时打印敏感环境变量。
每一种暴露方式，都可能给攻击者提供可直接使用的凭据。
真正决定后果的，是密钥对应的权限。一份数据库凭据可能暴露客户记录，一枚 Kubernetes 服务账号令牌可能让攻击者读取更多 Secret 对象，一份云凭据则可能打开 Kubernetes 之外的基础设施。
真正的风险范围，会覆盖所有信任这份已暴露凭据的系统。
GitGuardian 最近开展的三项调查，展示了凭据如何在软件交付系统中扩散，并暴露关联基础设施。
GitGuardian 研究人员调查公开暴露的 Kubernetes 凭据时，发现通过泄露的密钥可以访问 44 个活跃集群。这只是其中一项研究项目，而现实中每天都有更多凭据暴露在他们检查的集群中，有 4 个集群超过 10 个节点，最大的一个超过 200 个节点。可访问集群中有 30% 已经暴露超过两年，其中最早仍然有效的泄漏可以追溯到 2021 年。
其中一个案例源自一枚被嵌入公开 Docker 镜像的服务账号令牌，它可以直接访问一个 K8s 集群。该集群里还保存着更多凭据，最终，这把钥匙打开了私有容器镜像和 GitHub 组织。
同一项研究还发现了超过 2,000 份主机名仍可解析的容器镜像仓库凭据，其中 46% 仍然有效。这些凭据可以访问 309 个私有 Docker Hub 镜像，以及 730 个私有 GitHub 仓库。
一枚泄露的令牌，最终变成了访问更多密钥和更多系统的入口。
K03 与授权过度、集群到云环境的横向移动直接相关。被攻陷的凭据可以暴露攻击链上的下一份凭据。
GhostAction 供应链攻击最初于 2026 年 8 月 31 日至 9 月 30 日期间进行，影响了 772 个公开仓库，并针对 2,577 个密钥值。GitGuardian 研究人员最先发现了这次攻击。攻击目标是自动化流程使用的凭据，包括云密钥和容器镜像仓库凭据。
攻击期间，大多数工作流执行都需要人工审批，因此影响范围和受害人数受到了一定限制。不过在 10 月的后续攻击中，又有 346 个仓库受到影响，外部研究人员也确认凭据已被成功外传。
GhostAction 的目标就是 CI/CD 基础设施。由于部署流水线通常持有能够访问镜像仓库和云服务的凭据，影响自然会延伸到 Kubernetes。
攻击者拿到这些凭据后，可能直接访问合法部署自动化所使用的同一套基础设施。
因此，保护 Kubernetes 不能只盯着集群内部，还要控制负责构建和部署工作负载的系统。
2026 年 5 月，GitGuardian 研究人员发现了一个名为 Private-CISA 的公开 GitHub 仓库。这个名字乍看并不奇怪，因为 CISA 可能代表很多不同机构，但该仓库中包含 844 MB 明文密码、AWS token，以及属于美国网络安全和基础设施安全局的 Entra ID SAML 证书。为了贴近国内团队的云场景，可以把其中的 AWS token 理解为同类云访问密钥；原披露类型则是 AWS token。
暴露的文件包括 Kubernetes 清单、ArgoCD 配置，以及 Terraform 基础设施代码。
研究人员测试了其中许多凭据，发现它们仍然有效。
研究人员还找到了描述内部基础设施的凭据和文档。这些信息不仅暴露了系统如何配置、如何互联，还可能帮助攻击者识别高价值凭据，并判断这些凭据在哪里有效。
协调披露完成后，该仓库已经被下线。不过和任何安全事件一样，已经暴露的凭据仍然需要调查并采取适当的修复措施。
仓库扫描与凭据生命周期管理，是组织处理当前暴露以及后续持续风险的两项关键能力。
和 OWASP 的其他 Top 10 清单一样，这里给出的建议可以组成一套实用的风险治理基线，只不过这次聚焦的是 Kubernetes 凭据。
严格的 RBAC 可以限制哪些身份读取密钥，Namespace（命名空间）边界与 NetworkPolicy 可以限制工作负载之间的访问，静态加密则能保护存储在 etcd 中的敏感值。
凭据检测还要覆盖整个软件交付过程。源代码仓库、CI/CD 工作流和容器镜像，都可能在应用进入生产环境之前成为密钥扩散渠道。
安全团队必须审查已经暴露的凭据。即使团队不一定是这些凭据的最终“所有者”，但凭据一旦遭到滥用，团队仍然要负责处理后果。要确定修复优先级，就必须确认凭据是否有效、具有什么权限，以及实际被哪些服务使用。轮换和吊销可以清除已被攻陷的访问入口，收紧权限则能限制未来再次暴露时所能造成的影响。
工作负载身份联合（Workload Identity Federation）提供了缩短访问权限持续时间的机会。GitGuardian 的研究发现，有些 Kubernetes 凭据在首次暴露多年后依然有效。支持工作负载身份联合的 Kubernetes 工作负载，可以使用受信任身份换取外部服务的临时访问权限。短生命周期令牌既能缩短被窃凭据的有效时间，也能减少永久密钥的分发需求。
长期目标，是持续减少长期驻留的凭据，同时加强剩余凭据周围的控制。
Kubernetes 工作负载依赖的凭据来自企业环境的多个位置。开发者终端、源代码仓库和 CI/CD 系统都是凭据生命周期的一部分。
GitGuardian 通过三项相互连接的能力，帮助组织保护这一凭据层。
GitGuardian 可以在支持的代码仓库和开发环境中检测暴露的密钥，ggshield 则把扫描能力扩展到 CI/CD 工作流和容器镜像。
在配置为接入 Kubernetes 集群后，该平台会映射身份和基础设施上下文，帮助安全团队理解凭据被用在哪里，以及它们能提供什么访问权限。
找到凭据只是第一步，真正困难的是完成修复。安全团队需要确定优先级、展开调查，再采取正确措施降低风险。第一步就是判断凭据是否仍然有效，以及哪些服务依赖它。
GitGuardian 支持不同规模的团队开展调查和风险排序。流程中包括有效性检查，并会展示上下文风险信息，帮助团队协调凭据轮换、减少不必要的权限，同时避免影响生产环境可用性。
与其事后花大力气修复，不如提前把问题拦下来。
GitGuardian 为开发者和本地编码助手提供工具，在整个软件开发流程中防止密钥被加入代码或被使用。作为 GitGuardian 命令行工具，ggshield 支持开发者侧检查，也支持在 CI/CD 流水线中进行自动化扫描。AI Hooks 则会在智能体接触敏感信息时增加额外的检查节点。
Developer Endpoint Protection 把可见性延伸到开发者本地机器，因为凭据最容易在这类设备上集中。它可以帮助团队识别开发者电脑上风险最高的密钥，并为尚未遭到滥用或公开泄漏的明文密钥规划修复，也能为组织遭受信息窃取木马攻击时的处置提供清晰的优先级依据。
这些能力结合起来，可以帮助组织减少开发与生产环境中的密钥蔓延。
OWASP Kubernetes Top 10 清楚地说明，暴露的凭据可能让整个环境陷入风险。一枚泄露令牌就可能打通工作负载、云基础设施以及关联系统。
保护 Kubernetes 和其他生产系统，需要在整个凭据层建立可见性和控制能力。这个范围从开发者笔记本电脑延伸到代码仓库、CI/CD 流水线和生产工作负载。所有能够保存明文密钥的系统，都是凭据层的一部分。
GitGuardian 可以帮助团队获得这些控制能力：发现暴露的凭据、确定修复优先级，并阻止新的密钥在开发和生产环境中继续扩散。
现在开始使用 GitGuardian，主动掌控你的凭据层。
立即预约演示。
OWASP Kubernetes Top 10 是什么？
OWASP Kubernetes Top 10 是一份按优先级排列的清单，汇总了影响 Kubernetes 环境的最紧迫风险，依据来自社区持续发现和处理的真实问题。其中十类风险覆盖不安全的工作负载配置、过度宽松的授权、密钥管理失败、网络分段缺失、组件过度暴露、从集群向云环境横向移动、认证失效，以及日志记录和监控不足。
为什么 K03——Secrets Management Failures 值得重点关注？
凭据通常可以访问远超原始集群的系统，而密钥对应的权限决定了暴露后的具体后果。数据库凭据可能暴露客户记录，服务账号令牌可能让攻击者读取更多 Secret 对象，云凭据则可能开放 Kubernetes 之外的基础设施。K03 也与授权过度和集群到云环境的横向移动直接相关。
Kubernetes 环境中的密钥是如何暴露的？
OWASP 总结了六条常见路径：密钥被打进容器镜像，敏感值被放入 ConfigMap，密钥通过环境变量传递，凭据被提交到代码仓库，身份对 Secret 对象拥有过高的 WATCH 或 LIST 权限，以及密钥被写入应用日志。任意一条路径，都可能给攻击者提供可直接使用的凭据。
泄露的凭据如何导致 Kubernetes 集群失守？
GitGuardian 研究人员发现了 44 个可通过泄露密钥访问的活跃 Kubernetes 集群，其中 30% 已经暴露超过两年。一个案例中，被嵌入公开 Docker 镜像的服务账号令牌打开了一个包含更多凭据的集群，这些凭据又进一步打开了私有容器镜像和 GitHub 组织。一枚泄露令牌，最终变成了访问更多密钥和更多系统的入口。
GhostAction 是什么，为什么它与 Kubernetes 安全有关？
GhostAction 是一次供应链攻击，最初由 GitGuardian 研究人员发现。它影响了 772 个公开仓库，并针对自动化流程使用的 2,577 个密钥值，其中包括云密钥和容器镜像仓库凭据。后续攻击又影响了 346 个仓库。之所以会波及 Kubernetes，是因为部署流水线经常持有能够访问镜像仓库和云服务的凭据。
团队如何缩小 Kubernetes 凭据暴露后的爆炸半径？
使用严格的 RBAC 限制可以读取密钥的身份，通过命名空间边界和网络策略限制访问，并加密静态存储在 etcd 中的敏感值。在仓库、CI/CD 工作流和容器镜像中检测凭据，再检查其有效性、权限和实际使用情况，以确定轮换与吊销优先级。工作负载身份联合和短生命周期令牌，则能缩短被窃凭据的有效时间。
GitGuardian 如何保护 Kubernetes 凭据层？
GitGuardian 可以在支持的代码仓库和开发环境中检测暴露的密钥，ggshield 则把扫描扩展到 CI/CD 工作流和容器镜像。接入 Kubernetes 集群后，该平台会映射身份和基础设施上下文，有效性检查与上下文风险信息则帮助团队确定修复优先级。在预防方面，ggshield、AI Hooks 和 Developer Endpoint Protection 可以在密钥扩散之前将其拦截下来。