[flagged]
Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
51–55 of 55 posts
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#52Earlier quoted context omitted.
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.
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.
Protecting the secret from the host is a superset of protecting the secret from a workload.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#53I used to run a similar company in this space. gearsec.io My 2 cents are that no one we spoke was comfortable with us having mitm plus access to their secrets no matter how much we told we'll host it in your cloud. The few who agreed were rigorously testing our product and asked for code SBOMs before even a pilot. Infiscals agent vault might be the best middle ground for this kind of setups I feel sometimes
Thank you for the insights! We thought about this when we started working on the project and this is among the reasons we decided to go the open-source route. We think building in the open make it easier to earn users trust and give opportunities for them to audit the code and the dependencies. Also, note that with Kloak user secrets and traffic never leave the user environment as we are not a SaaS product which make security requirements more relaxed.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#54There 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.
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.
You are already doing a MITM, so some one is placing the trust in you as a intermediary. In reality the content distribution networks fronting any of the API operations have already muddied the water at this point. You are well into your rights to recalculate the signature for the payload and replace it with the secret key.
Re: Show HN: Kloak, A secret manager that keeps K8s workload away from secrets
#55Earlier quoted context omitted.
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.
You are already doing a MITM, so some one is placing the trust in you as a intermediary. In reality the content distribution networks fronting any of the API operations have already muddied the water at this point. You are well into your rights to recalculate the signature for the payload and replace it with the secret key.
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)