neo2006 6 hours ago

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.

▲

cassianoleal 4 hours ago | parent | next [-]

Yes, please! :)

▲

subhobroto 4 hours ago | parent | prev [-]

> The main challenge is to find a flow to signal to kloak what to rewrite and how to inject kloaked secrets to the workload

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?

	▲	neo2006 4 hours ago \| parent [-]
		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.