<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Zero-Trust on A cup of coffee</title><link>https://a-cup-of.coffee/tags/zero-trust/</link><description>Recent content in Zero-Trust on A cup of coffee</description><generator>Hugo</generator><language>en</language><copyright>Copyright © 2026</copyright><lastBuildDate>Sat, 02 May 2026 09:37:14 +0200</lastBuildDate><atom:link href="https://a-cup-of.coffee/tags/zero-trust/index.xml" rel="self" type="application/rss+xml"/><item><title>Kloak: kernel-space secret injection via eBPF on Kubernetes</title><link>https://a-cup-of.coffee/blog/kloak/</link><pubDate>Sat, 02 May 2026 08:00:00 +0200</pubDate><guid>https://a-cup-of.coffee/blog/kloak/</guid><description>When an application gets breached, the first thing an attacker will do is exfiltrate whatever data they can reach. From customer data to authentication tokens, secrets are target number one (goodbye to your GitHub PATs, your Slack bots in #general channels, your Mailchimp tokens, OpenAI keys, and so on). You&amp;rsquo;ll have to revoke everything, assuming the attacker already had access.
When thinking about secret management, you think of OpenBao, External Secrets Operator, or sidecars that inject secrets — it works, but the application still ends up with the secret content in memory (and so does an attacker who compromises it).</description></item></channel></rss>