加载失败
Kloak 是一个面向 Kubernetes（容器编排系统）的 secret manager：它先把真实凭据替换成占位 secret，再在应用即将向允许的目标发起 TLS 连接时，用 eBPF（Linux 内核可编程框架）把真实值临时换回。讨论里补充了当前实现的边界：主要支持 OpenSSL（常用 TLS/SSL 加密库）3.0-3.5 和 go-tls（Go 语言的 TLS 实现），并且要处理加密前后缓冲区、跨 packet 改写和 TLS session hash 的一致性。评论还把话题扩展到非 Kubernetes 场景，例如 docker-compose（多容器编排工具）、Incus（容器与虚拟机管理平台）和原生 Linux，并询问在 EKS（AWS 托管 Kubernetes）或 DigitalOcean 云上是否能部署。项目方表示它以 privileged DaemonSet（每节点一个 Pod 的 K8s 工作负载）形式运行，理论上也能适配其他调度器，但真正难点是如何向系统传达哪些流量该改写、哪些占位 secret 该注入。
项目方说明 Kloak 作为 Kubernetes controller 运行，会先把工作负载里的真实 secret 换成占位符“kloaked secrets”，等应用向允许的 host 发起请求时，再用 eBPF 在最后一刻把真实值换回。有人追问它是不是在 kernel 层读 packet、改字节序列，以及跨 packet 边界怎么办。回复解释说，secret 的识别发生在加密前的 user buffer，真正的改写在加密后的 kernel buffer；如果 secret 跨了两个 packet，就分两次改写，并同步更新 TLS session hash，避免破坏 TLS frame。
有评论希望把同样的 eBPF 机制用到自托管家庭项目上，不只限于 Kubernetes，还包括 docker-compose（多容器编排工具）、LXC/QEMU、Incus（容器与虚拟机管理平台）以及原生 Linux。项目方回应说，从技术上讲并不受调度器限制，关键障碍是如何通知 Kloak 该改写哪些流量，以及如何把占位 secrets 注入到目标 workload。另一条建议是去和 Incus 社区讨论集成方式，说明这类方案的落地很依赖编排系统的接口设计。
有人认为这类 out-of-band secret 处理对 AI controlled workflows 很有用，并直接问它在云端 Kubernetes 里能否工作，尤其是 AKS/EKS（托管 Kubernetes 服务）。回复说已经在 EKS（AWS 托管 Kubernetes）和 DigitalOcean 云上测试过，结果可用。部署方式是把 Kloak controller 做成 privileged DaemonSet（每个节点一个 Pod 的工作负载），让它能接触宿主机并给节点上的所有 Pod 挂载 eBPF 程序。
有人担心 controller 同时跑在 control plane 和 data plane，建议把职责拆开。项目方解释说 controller 只是把 eBPF 程序下发到内核，并按应用或 cgroup（Linux 控制组）做绑定，因此更像 control plane；真正处理流量的数据面逻辑都在 eBPF 里。后续追问也说明，讨论焦点不只是功能本身，还包括这种 Kubernetes 风格的控制/数据分层是否清晰。
评论区顺手聊起名字：Kloak 在丹麦语里像是“sewer（下水道）”，还被联想到拉丁语 cloaca。项目方也自嘲成了“secrets sewers”，并希望大家多提产品反馈而不只是吐槽名字。这个小插曲更多体现 HN 文化里的双关和命名审美。
eBPF: Linux 内核里的可扩展字节码与钩子机制，允许在内核路径上动态观测和改写数据流。
Kubernetes controller: 监听集群状态并持续调谐资源的控制器；Kloak 以此形式工作。
DaemonSet: Kubernetes 中让每个节点都运行一个 Pod 的工作负载类型，适合做节点级 eBPF 绑定。
control plane / data plane: 前者负责下发策略和协调，后者负责实际处理流量；这里被用来界定 controller 与 eBPF 的职责。
TLS session hash: TLS 会话内部用于校验和一致性的状态，改写加密数据后需要同步更新。
cgroup: Linux 的控制组机制，用来把进程或工作负载分组并绑定到相应的内核操作。