在 Kubernetes 环境中，密钥管理一直是安全运维的核心挑战。传统方案将 Secret 以 Volume 形式挂载到 Pod 或注入为环境变量，这意味着应用进程始终有机会访问到明文密钥。一旦容器被攻破，攻击者可以通过进程内存、Dump 文件或日志轻易获取这些凭证。Kloak 提出了一种全新的思路：在网络层拦截流量，用哈希占位符替换真实密钥，实现应用与密钥的彻底解耦。
传统方案的固有风险
Kubernetes 原生提供两种 Secret 使用方式：环境变量注入和 Volume 文件挂载。环境变量的致命问题在于它会进入进程的全局环境空间，任何能读取 /proc/[pid]/environ 的代码都能获取明文密钥，且日志框架、错误堆栈或子进程继承都可能泄露这些敏感数据。Volume 挂载虽然可以通过文件权限限制访问，但密钥仍然以明文形式存在于容器文件系统内，容器镜像、持久卷或节点磁盘被访问时同样面临泄露风险。更关键的是，这两种方式都无法避免应用代码直接接触密钥 —— 只要进程拥有读取权限，攻击者通过代码注入或内存 dump 同样可以获取密钥内容。
Kloak 的运行时注入架构
Kloak 采用纯 eBPF 实现，无需额外部署 Sidecar 或修改 CNI 插件，其核心思路是为每个 Secret 生成唯一的 ULID 占位符，然后在网络层面将占位符替换为真实密钥。具体工作流程分为三个步骤：首先在 Kubernetes Secret 上添加标签 getkloak.io/enabled=true 并可配置允许使用的主机列表，Kloak Controller 会监听 Secret 变化并生成对应的哈希占位符；应用代码中不再使用真实密钥，而是配置类似 Authorization: kloak:MPZVR3GHWT4E6YBCA01JQXK5N8 的占位符；当 Pod 发出 HTTPS 请求时，eBPF 程序在网络层拦截流量，将占位符替换为真实密钥后转发，整个过程应用进程从未见过明文凭证。
从架构角度看，Kloak 包含 Control Plane 的 Controller 组件负责监听 Secret 并管理 eBPF 程序，以及 Data Plane 的 eBPF 代理运行在每个节点上执行流量拦截和密钥替换。这种设计确保密钥只在 Kloak 组件和上游服务之间流转，应用 Pod 的网络出口已经携带真实凭证，但应用本身无法接触到这些数据。
核心安全优势与落地参数
Kloak 的设计带来了几个关键安全收益：密钥对应用完全不可见，即使容器被攻破且攻击者获得代码执行权限，也无法通过内存读取或日志查看获取真实凭证，因为应用发送的始终是占位符；支持细粒度的主机访问控制，通过 getkloak.io/hosts 标签可以限制特定密钥只能用于指定域名，防止凭证滥用；由于 eBPF 程序运行在内核空间，性能开销极低，官方宣称对请求延迟的影响可忽略不计；最重要的是对应用完全透明，无需引入任何 SDK 或修改代码，现有的 Go、Java、Python、Node.js 应用均可直接使用。
在生产环境中落地时，有几个关键参数值得关注：Kloak 默认只处理 HTTP 请求的 Header 替换，对于需要保护其他类型密钥的场景需要评估覆盖范围；eBPF 程序依赖特定的内核版本，通常需要 Linux 4.18 以上才能完整支持；由于替换发生在网络层，无法解决应用内部其他形式泄露（如日志中打印的密钥），需要配合日志审计和代码扫描形成完整防护体系；Secret 更新后占位符可能需要同步刷新，建议配置合适的重试机制应对 Controller 与 eBPF 程序之间的同步延迟。
实践建议与限制
对于已经在生产环境使用 Volume 挂载或环境变量注入 Secret 的团队，迁移到 Kloak 需要评估几个方面：现有应用代码中硬编码的 API Key 需要替换为占位符格式，这可能涉及配置文件的批量修改；Kloak 目前仅支持 HTTPS 流量替换，HTTP 或非 TLS 协议的密钥保护场景暂不适用；由于替换发生在网络层，需要确保 Kloak 的 eBPF 程序能够正确识别目标流量，对于使用自定义网络库或非标准 HTTP 客户端的应用可能需要额外验证。
总体而言，Kloak 代表了一种将密钥管理从应用层剥离到基础设施层的思路，这与零信任原则高度契合 —— 不信任应用代码会妥善保管密钥，而是在更底层实现密钥的按需投送。对于追求深度防御的 Kubernetes 集群，Kloak 提供了一种无需修改应用即可提升密钥安全性的工程化路径，尤其适合 API Key、Token、证书等需要频繁轮换的敏感凭证管理场景。
资料来源：Kloak 官方文档（https://getkloak.io）。