Show HN: Kloak, A secret manager that keeps K8s workload away from secrets

Awesome project! We need more eBPF projects, and congrats on launching.

Assuming I hijack a production pod, can I not just make an http call to myself with the `kloak:...` secret and get back the real secret? Is there a way to validate destination?

Hey, we're the spinning-factory team, the folks behind Kloak. Kloak runs as a Kubernetes controller. It swaps the secrets in your workloads for harmless placeholders we call kloaked secrets, then uses eBPF to substitute the real secrets back in at the last moment — right when your app makes a request to an allowed host. Today, Kloak works with any app using OpenSSL 3.0–3.5 (statically or dynamically linked) or go-tls (Go 1.25 and 1.26). Support for more TLS libraries (GnuTLS, BoringSSL, and others) and additional Go versions is on the roadmap. Kloak is open source under the AGPL, contributions are welcome! We are also happy to hear any feedback and answer any question for the HN community.

Was just talking about this the other day - although more in-line with a custom controller to replace _all_ secrets / env variables used at runtime automatically (LD_PRELOAD get_env ?). Recognize this serves a different use case - I was trying to only decrypt KMS encrypted secrets in-memory / in-flight so that an attacker would have a harder time reading secrets in-cluster or in pod shell.

Such a sick idea, and incredibly useful. Would be nice if it integrated directly with secrets managers RE: ESO

I've heard one way to acheive this is by using api proxies/gateways. you can store secrets in a vault if you wish, but with a proxy, your app makes requests as usual without using secrets, its requests are then intercepted by the proxy to add authentication information transparently.

The added benefit is that you can also manage things like api rate limits, and implement all sorts of cool monitoring and api-specific threat detection centrally. I don't know of a way to do this outside of cloud provider services though.

Architecturally speaking, you have an environment that is at the same level of trust with respect to the data it processes, anything in there is unsecured, but all interactions outside of the system passes through a gateway proxy that manages all of what i mentioned earlier, including secret management.

Yeah, so Kloak is Danish for sewer.

This is pretty cool, nice project. Can you expand on what threat model this combats?

Also, does the replace op happen only for specific fields in HTTP, or for every matching string in the request? I can imagine the latter if you want to support non-standard authentications methods, though there's always the edge case where the secret string placeholder is not used as a secret and should not be replaced.

This is pretty awesome. Super relevant for the time because AI controlled workflows are desperate for a out of band solution like this.

The main thing I wonder is how well supported is it in cloud environements? AKS/EKS/etc?

There is also a model where the applications sign the payload using the secret, AWS is a big user of that across all its API's.

You should split your controller - it is running in both the control and data planes. Idea is good though, wish you luck.

how does this compare to something like google secrets manager?