在 Kubernetes 安全实践中，secret 资源的保护一直是核心挑战。传统方案聚焦于如何安全地存储和分发凭证，但无论加密多么严密，一旦 Pod 获得了 secret 的访问权限，攻击者通过容器逃逸或凭证轮换前的窗口期仍有可能窃取敏感数据。Kloak 提供了一种截然不同的安全思路 ——让工作负载从根本上无法接触 secret 资源，通过在网络层将哈希占位符实时替换为真实凭证，实现 secrets-free pods 的目标。
传统 secret 管理的困境
Kubernetes 原生的 Secret 资源本质上是一种 Base64 编码的 ConfigMap，存储在 etcd 中并通过 API Server 分发到 Pod。无论使用多么严格的 RBAC 策略或多层加密，Pod 一旦通过卷挂载或环境变量获取了 secret，应用程序就拥有了该凭证的完整访问权限。这意味着攻击者只需要获取容器的文件系统或进程内存，就能提取出明文 secret。外部 secret 管理工具（如 Vault 的 Sidecar 注入或 Secrets Store CSI Driver）虽然增强了安全管理，但本质上仍是将 secret 推送给 Pod，攻击面并未从根源上缩小。
另一个关键问题是凭证的生命周期管理。即使实现了自动轮换，在轮换生效的窗口期内，旧凭证仍然有效且可能被窃取。更棘手的是，许多遗留应用将凭证硬编码在配置文件或代码仓库中，导致凭证一旦泄露就难以撤销。
Kloak 的 secrets-free 设计理念
Kloak 的核心创新在于重新定义了 Pod 与 secret 之间的关系。传统模式是「Pod 获取 secret 并保管 secret」，而 Kloak 转变为「Pod 使用哈希占位符，Kloak 在网络层动态替换」。应用容器全程不知道真实凭证的存在，自然也无法泄露它。
具体实现上，管理员只需为 Kubernetes Secret 添加特定标签 getkloak.io/enabled="true"，Kloak Controller 会自动为每个 secret 值生成一个唯一的 ULID（统一唯一标识符）作为哈希占位符。这个占位符被设计为应用配置的一部分，例如在 HTTP 请求头中使用 Authorization: kloak:MPZVR3GHWT4E6YBCA01JQXK5N8 格式。应用程序完全不知道这个哈希值对应什么真实凭证，甚至不需要知道凭证的存在。
当 Pod 发起 HTTPS 请求时，Kloak 的 eBPF 程序在网络层拦截流量，识别出哈希占位符，然后从 Kloak 的安全存储中获取对应的真实凭证，替换请求中的占位符后再转发到目标服务。整个过程对应用程序透明，无需修改任何代码。请求离开 Pod 时已经携带真实凭证，但 Pod 内部的进程从未见过这个真实值。
防护边界与隔离保证
理解 Kloak 的防护边界是正确评估其安全价值的关键。Kloak 实现的隔离保证可以从三个维度来定义。
网络层的凭证隔离是 Kloak 最核心的防护边界。应用进程只能接触到哈希占位符，真实凭证的注入发生在 eBPF 层面，不经过用户空间。这意味着即使攻击者成功实现了容器逃逸，获得了宿主机的部分控制权，他们也无法从 Pod 的文件系统、环境变量或进程内存中提取真实凭证，因为这些位置上根本不存在真实值。Kloak 的这个设计从根本上改变了攻击者的窃取目标 —— 从「获取 secret」转变为「攻破 Kloak 本身」，后者需要更高的攻击成本。
主机级别的访问控制是第二层防护。Kloak 支持通过 getkloak.io/hosts 标签限制每个 secret 只能用于特定的目标主机。这是一种细粒度的访问控制机制，防止凭证被滥用于未授权的服务。例如，一个用于访问 AWS API 的凭证只能被替换到发往 AWS 域名的请求中，如果攻击者试图将这个凭证用于其他攻击路径，Kloak 会拒绝替换。这一机制有效缩小了凭证泄露后的爆炸半径。
零侵入性部署是 Kloak 区别于其他 secret 管理方案的重要特性。它不需要在每个 Pod 中注入 sidecar 容器，不需要修改应用程序代码，也不依赖于特定的编程语言或框架。Kloak 纯粹运行在 Linux 内核的 eBPF 层，通过网络流量拦截实现功能。这意味着现有的数十个微服务可以零改动地迁移到 secrets-free 模式，大幅降低了采用门槛。
与现有安全方案的互补关系
Kloak 并不是要替代所有的 secret 管理工具，而是填补了运行时安全的空白区。企业仍然需要 Vault 或 AWS Secrets Manager 这样的后端来安全存储和轮换凭证，需要 Kubernetes RBAC 限制谁可以创建和修改 Secret 资源，需要审计日志记录 Secret 的访问历史。Kloak 在这个基础上增加了最后一层防护：在应用程序运行时彻底隔离凭证。
一个典型的多层安全架构可能是：使用 Vault 存储主 secret，通过 Secrets Store CSI Driver 以加密形式注入到集群，Kloak 在 Pod 网络层拦截并替换为运行时凭证。攻击者需要同时攻破 Vault、CSI Driver 和 Kloak 三层防护才能获得真实凭证，这大幅提升了攻击难度。
对于已经投入生产的 Kubernetes 集群，Kloak 的渐进式部署能力也非常有价值。企业可以从单个命名空间的非关键工作负载开始试点，验证哈希占位符替换的可靠性，确认对业务延迟没有显著影响，然后逐步推广到全集群。整个过程中应用代码无需任何改动，部署风险可控。
关键部署参数与监控要点
在生产环境中部署 Kloak 时，有几个关键参数值得注意。首先是占位符格式的选择，Kloak 使用 ULID 作为默认哈希算法，长度为 26 个字符，发生碰撞的概率极低。对于超大规模集群（超过十万量级的 Pod），可以考虑为不同业务域使用不同的占位符前缀以进一步降低碰撞风险。
其次是 eBPF 程序的资源限制。Kloak 的数据平面运行在内核空间，需要为 Controller 组件配置适当的 CPU 和内存配额。根据官方基准测试，单个 Kloak Controller 实例可以处理每秒数千次的替换请求，对于大多数企业级工作负载已经足够。如果集群规模非常大，可以考虑部署多个 Controller 实例并通过 Kubernetes Service 负载均衡。
监控方面需要关注几个核心指标：替换成功率（反映 Kloak 是否正常工作）、替换延迟分布（评估对业务响应时间的影响）、被拒绝的替换请求（可能意味着配置错误或攻击尝试）。建议将这些指标接入 Prometheus 并设置告警阈值，确保在 Kloak 出现异常时能够第一时间响应。
此外，Kloak 的日志审计功能也非常重要。每次占位符替换都会记录原始请求的源 Pod、目标主机和使用的占位符 ID，这些审计日志是排查问题和满足合规要求的基础。建议将日志发送到独立的 SIEM 系统，与应用日志隔离存储。
防护边界的局限性
客观来说，Kloak 并非银弹。它的防护范围严格限定在网络层，对于非 HTTP 协议的凭证使用场景（如数据库连接字符串、gRPC 认证令牌等）无能为力。对于这类场景，仍需依赖传统的 secret 管理方案。
另一个需要注意的限制是：如果攻击者能够修改 Pod 的网络配置（例如通过 DNS 欺骗或中间人攻击），他们可能截获已经替换过的真实凭证。Kloak 本身不提供 mTLS 保护，应用层仍需启用 HTTPS 证书校验。这意味着 Kloak 是纵深防御的一环，而非唯一的防线。
重新思考工作负载安全
Kloak 代表的 secrets-free pods 理念反映了一个更根本的安全范式转变：与其在获取后保护 secret，不如从设计上让 secret 永远不会到达工作负载。这种「否定的安全」（security by negation）思路在云原生环境中具有重要的示范意义。当攻击者的目标从「获取某物」变成「根本不存在可获取之物」时，攻击成本急剧上升，防御的有效性也随之提升。
对于追求零信任架构的团队，Kloak 提供了一条可行且低侵入的实现路径。它不要求大规模重构应用，不依赖特定的云服务商，也不引入复杂的密钥管理基础设施。在 Kubernetes 安全日益重要的今天，这种从网络层入手的轻量级方案值得在实际项目中进行评估和试点。
资料来源：Kloak 官方文档（https://getkloak.io）