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.
- 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.
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.
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.
It's perfectly fine for you to say non-Kubernetes isn't either your focus or on your 90 day roadmap :)
https://discuss.linuxcontainers.org/t/how-to-best-ask-questi...
- 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)?
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?
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.
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.
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.
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 main thing I wonder is how well supported is it in cloud environements? AKS/EKS/etc?