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.

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