<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>External-Secrets on Danilo Falcão da Silva</title><link>https://falcao.org/tags/external-secrets/</link><description>Recent content in External-Secrets on Danilo Falcão da Silva</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 20 May 2026 22:25:00 -0300</lastBuildDate><atom:link href="https://falcao.org/tags/external-secrets/index.xml" rel="self" type="application/rss+xml"/><item><title>Where to Hide Kubernetes Secrets: AWS, Azure, GCP, and On-Prem Compared</title><link>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</link><pubDate>Wed, 20 May 2026 22:25:00 -0300</pubDate><guid>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</guid><description>&lt;p>The Kubernetes &lt;code>Secret&lt;/code> object is a YAML manifest with a base64-encoded
value in it. That&amp;rsquo;s the entire encryption story. Anyone with &lt;code>get&lt;/code>
permission on the namespace can read every credential the workload
holds. &lt;strong>Base64 is not encryption.&lt;/strong> It is barely obfuscation.&lt;/p>
&lt;p>Teams discover this the wrong way — usually during a security
review, occasionally during an incident — and the next question is
always the same: &lt;em>so where do the real secrets live?&lt;/em>&lt;/p></description></item></channel></rss>