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?
Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
21–30 of 55 posts
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#22Also, 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.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#23This 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.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#24This 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.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#25Hey, 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…
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.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#26Earlier quoted context omitted.
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 :)
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…
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#27Earlier quoted context omitted.
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...
Thank you! We will reachout and see what can be done
- What's the best way to discuss this specific topic with you? As an https://github.com/spinningfactory/kloak/issues or something else?
- My specific usecase is to not need Conjur Secretless Broker (https://github.com/cyberark/secretless-broker) - my understanding of eBPF is entirely superficial but from a 30k ft view, it looks like this can not only replace it but would be a far efficient solution (Conjur would be a user-space proxy while kloak would be at lower levels of abstraction)?
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#28Earlier quoted context omitted.
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 :)
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…
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?
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#29Hey, 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…
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.