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

nneo2006 about 6 hours ago 35 commentsRead Article on getkloak.io

HI version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

77% Positive

Analyzed from 1130 words in the discussion.

Discussion (35 Comments)Read Original on HackerNews

notepad0x90•about 2 hours ago

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.

neo2006•about 1 hour ago

For egress proxy the app need to:

- send traffic to the proxy (either in a non transparent way or using routes or even ebpf to redirect traffic to the proxy transparently)

- trust the proxy certs or use plain http/TCP to the proxy

With kloak, the app don't need any modification and you avoid a single point of failure (aka egress proxy). Each app has an independent ebpf program attached to it that can survive the control plane going down and don't need to trust any special certs or change the endpoint it sends traffic to.

neo2006•about 5 hours ago

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.

arpinum•about 2 hours ago

your architecture page is empty. https://getkloak.io/docs/architecture/overview.html

For security products trust is important. writing your website copy by hand will help you build trust. If the design and content does not look human written it will lower adoption.

neo2006•about 2 hours ago

Thank you for the feedback! We are currently shorthanded so we relied on AI a lot for writing our docs, we reviewed that doc as much as we could but definitely there is room for improvement. We will try to get better at this. In the mean time, if you find any discruptency with the docs or anything that we can correct please open an issue and we will get to it ASAP.

koolba•about 4 hours ago

So it reads the packets and replaces the byte sequences at the kernel level? How does that work across packet boundaries?

neo2006•about 4 hours ago

Secrets are detected before encryption in the user buffer but rewrites happen post encryption in the kernel buffer to be sent on the wire.

packets boundaries are not an issue because detection happen at the SSL write where we have the full secret in the buffer and its position so we can know at rewrite time that the secret is cross 2 packets and rewrite it in 2 separate operations. We also have to update the TLS session hash at the end to not corrupt the TLS frame.

subhobroto•about 4 hours ago

This is fantastic! I need this. however, for my self-hosted home projects that are containerized but where I don't use Kubernetes, is there a way for me to use a version of Kloak that does the same eBPF magic on docker-compose or LXC/QEMU (Incus) stacks?

It's perfectly fine for you to say non-Kubernetes isn't either your focus or on your 90 day roadmap :)

NewJazz•about 4 hours ago

Yeah you might have to go talk to incus folks on how to integrate this together.. They are fairly capable, might have some good direction.

https://discuss.linuxcontainers.org/t/how-to-best-ask-questi...

neo2006•about 3 hours ago

Thank you! We will reachout and see what can be done

neo2006•about 4 hours ago

Thank you! We appreciate your enthusiasm! :-) From technology perspective nothing prevent kloak to do rewrite on any workload scheduler or even without a scheduler (native Linux). The main challenge is to find a flow to signal to kloak what to rewrite and how to inject kloaked secrets to the workload. TBH supporting other technologies is not something we thought about but we can definitely consider if there is an ask for it from the community.

cassianoleal•about 2 hours ago

Yes, please! :)

subhobroto•about 2 hours ago

> The main challenge is to find a flow to signal to kloak what to rewrite and how to inject kloaked secrets to the workload

Would it be realistic or reasonable to detect a header like `X-kloak-ENABLED` or specific endpoints in the case of HTTP?

Similar for wire protocols like PostgreSQL or gRPC?

Our would a usermode proxy be easier but not preferred due to overhead?

mrweasel•about 5 hours ago

Yeah, so Kloak is Danish for sewer.

WJW•about 5 hours ago

More or less straight from Latin?

https://en.wikipedia.org/wiki/Cloaca_Maxima

neo2006•about 4 hours ago

I guess we are the secrets sewers then! :D We would love to hear what you think about it beyond the name though.

anthonyskipper•about 3 hours ago

I think it is funny that it's sewer, because a sewer is also a underground way around things, which is a good description of the out of band solution here. So the name checks out.

neo2006•about 3 hours ago

It was not intended! We were trying to make it sound like a cloak with a kubernetes K but I guess this explanation actually checkout better!

giladd•about 3 hours ago

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.

neo2006•about 3 hours ago

The main threat model is application leaking secrets: - Internet facing app that could potentially be hacked and bad actor exfiltrating secrets - AI agent that can exfiltrate secrets through prompt injection for example or context poisoning - The general use case where a secret can be for example inject by mistake in logs for instance

__turbobrew__•about 2 hours ago

How does this compare with TPUs? Can you not have secrets in the TPU which cannot be accessed directly by apps, solving this threat vector? I get that you want compatibility with popular libraries, but I wonder if the actual solution is to use hardware support to enforce the secret boundaries.

neo2006•about 1 hour ago

I'm not super familiar with TPUs and Trusted execution environments but my understanding is that it serve a different threat model.

TEE aim to protect a certain workload from the host to avoid another workload on the same host from steeling secrets. Kloak aim is to protect the secret from the workload itself not the host.

boistrous•about 2 hours ago

we currently support rewrites for specific hosts and IPs and we have an open issue for supporting rewrite for specific headers for http/http2

sandeepkd•about 2 hours ago

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.

neo2006•about 2 hours ago

This is not something we support currently. We will need to do some research on ways to support it.

The main hurdle is that we can't rewrite secrets in any of the user buffers as this will defy our threat model and signing is usually done in user space.

anthonyskipper•about 4 hours ago

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?

spinningfactory•about 4 hours ago

It should work in cloud environments, We tested it on EKS and digital ocean cloud so far, and it works. The kloak controller is deployed as privileged daemonset that have access to the underlying host and can perform eBPF attachment operations on all the pods on that host.

boistrous•about 3 hours ago

gcp and aks were going to be the next ones on the testing list, but life sometimes gets in the way !

captn3m0•about 4 hours ago

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

neo2006•about 4 hours ago

Thank you! Not really, the controller is not doing dataplane per-say, it only pushes eBPF programs to the kernel for the relevant apps/cgroups so that could be considered control-plane. The full data-plane run in eBPF.

NewJazz•about 4 hours ago

Aiui the controller is only running in the control plane, and the ebpf programs are in the data plane?

neo2006•about 3 hours ago

yes, that's right!