neo2006

This is, for the time being, mostly an experiment. I was able to get consistent results where a diverse community of agents could provide a more accurate answers for tasks that they would fail if asked to perform individually.

yes I agree and we actually already do that for TLS when rewriting secrets after encryption but my point is about the fact in our threat model we consider the app as an adversary so we don't want to use any of its buffers to rewrite secrets because it would be trivial for an adversary to reread the buffer after rewrite and get the secret. The way we overcome this is by listening to the user buffer recording all the data we need to rewrite the secret without writing anything. We go back later in the kernel buffer meant to be sent to the network and not accessible to the user app and perform the rewrite. For API keys used to sign the request we need to do something similar which could be challenging within ebpf (maybe doable I'm not sure)

Actually we have 2 applications along those boundaries you described. a webhook app that manage kubernetes manifest and another to inject the ebpf code and manage the ebpf maps.

Thank you for the feedback though! I think we need to clarify the doc to make that separation clear. I will open an issue for that and we will work on it.

Thank you!

We are planning to integrate with external secret operators, like AWS secret manager or Openboa/Vault so users can benefit from an end to end secrets protection. secret encryption/sealing at rest (through secrets managers) and protecting secrets from in-memory exfiltration attacks with kloak.

The idea is to let the ESO handle the secret at rest and delivering it to Kloak that then would continue to do the kloaked secret rewrite so the secret will only be available in a non encrypted form in Kloak. We can even push the concept further and do KMS decryption just in time to reduce the window where the secret is available.

Thank you! I agree, each architecture have its pro and cons. If an egress gateway is available and can handle secrets it's definitely a viable solution.

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.

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.

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.

The way we thought about it is from the lense of 2 personas: - a persona that control the control plain side, what secret to distribute to which user and what hosts they are allowed to send that secret to (probably platform team or secops team) - a persona that represent the user that need to reach host X with secret Y (probably the dev team)

based on this secret rewrite signal need to be out of band and not part of the request it self or the whole model will fall apart.

We already have the intention to support rewrites for specific headers but those headers are defined by the first persona out of band too.

btw, we support rewrite for postgres protocol for db password.

yes please open an issue on https://github.com/spinningfactory/kloak/issues and we can discuss this. I'm not familiar with secretless-broker but we can definitely see if that use case fit with kloak and get into more specifics on how you can help.

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.

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

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!

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

yes, that's right!

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.

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.

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.

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

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.

it's not a war Netanyahu is killing innocent people and taking a full population hostage.

Also, most of the people in Gaza are not Hamas members and are regular civilians. What Natanyahu is doing is basically analog to the following:

A killer take a member of your family as a hostage (Hamas in this case is the killer) so you decide to kill a member of their family every hour until they release your beloved one. Do you think that this is acceptable or are you trying to make it acceptable?

If we want to include the cost of a code review into the equation we should also include the cost of fixing a big that made it to production which is in most of the cases higher then code review. Skill is not a factor here, I work and worked with some of the best engineers in the world and everyone write buggy code sometimes. Software engineering is a complex practice. If you are writing some prototyping code or some code that will never make it to production or in a very early stage of a startup, sure I can understand your point.

I fully agree, we also do this and this is the design review I alluded to. That said, I think both have different purpose. The design review is more about the approach and the high-level implementation. The code review is about the implementation details. Also, a great aspect often overlooked around code review is that it's a great teaching tool if used right. Asking question go a long way and make both the reviewer and the reviewee learn. Code review is often looked to as a senior watching over what juniors are doing. In my experience it should be done for all levels and even juniors should review seniors PR as they can bring novel perspective and at least learn from the code by reviewing it.

I often stack PRs to emulate the practice described by Mitchell but it's not ideal as if you need to change an underlying PR l, you need to rebase all of the dependent PRs.

I don't see code review as an overwatch but a good communication tool and a way to think about problems collectively. Code review reduce bugs because it permit to have people think about the problem from multiple angles. About decisions, I think important design decisions need to be taken prior to the code review steps ,and also reviewed. I'm not sure what context you worked in that gave you that opinion about code review being a sign of distrust and I think the problem lay within the culture in those places not the code review practice it self.

If you are going through writing the do-nothing script anyway why not do a do-something script and remove the error prone human out of the loop, it also can serve as documentation and if you are disciplined enough to never make a change other then trough the automation you can have the benefit of source controlling it and have documentation with historical context

I'm not saying that you will never find bugs in someone PRs I'm just saying it shouldn't be your first intention, your first intention should be to understand it and be convinced by it. Finding bugs will be a side effect of that. If you reading the code to execute it in your head and find all the weird combination that could trigger a core dump, you should probably check if the author wrote tests for those use cases instead and comment about missing tests. Genuine interest in others work can go a long way compared to imagining how would you solve it like the article author said.

90% of a code review is not about finding THE BUG in the PR but asking questions and making the author find his own bugs or learning something from him. If you are performing a code review hunting for bugs you already lost your humility and think you are better then the PR author.

That's a simplistic way of defining security needs. for example, you can be a dissident originated from a country that threaten your life and need an extra layer of security to avoid being blackmailed or killed.

What about all the overhead in testing that using a timestamp instead of boolean will introduce? Specially if you end up not needing it