<p>While I developed an API server, I needed to give some account information to API server, which should not be shown to anyone.
K8s recommends secret for this kind of situation, so I used.</p>
<p>But I wonder if the secret is really secret.
Secret is just base 64 &quot;encoded&quot; text, not &quot;encrypted&quot;.</p>
<p>When I see an arbitary secret like below,</p>
<pre><code>namespace: ZGVmYXVsdA==
</code></pre>
<p>I can easily know the real value of it by decoding.</p>
<pre><code>namespace: default
</code></pre>
<p>In such a this situation, is secret really helpful for security?
What I know about the security advantage of secret is that it is on-memory not on-node file system.
But I think that is not enough for security.</p>
<p>Thank you.</p>

<p>From <a href="https://kubernetes.io/docs/concepts/configuration/secret/#risks" rel="nofollow noreferrer">Kubernetes Secrets documentation</a>:</p>
<p><strong>Risks</strong></p>
<ul>
<li>In the API server, secret data is stored in etcd(<strong>by default, etcd data is not encrypted</strong>); therefore:
<ol>
<li><strong>Administrators should enable encryption at rest for cluster data</strong> (requires v1.13 or later).</li>
<li><strong>Administrators should limit access to etcd to admin users.</strong></li>
<li>Administrators may want to wipe/shred disks used by etcd when no longer in use.</li>
<li><strong>If running etcd in a cluster, administrators should make sure to use SSL/TLS for etcd peer-to-peer communication.</strong></li>
</ol>
</li>
<li>If you configure the secret through a manifest (JSON or YAML) file which has the secret data encoded as base64, sharing this file or checking it in to a source repository means the secret is compromised. <strong>Base64 encoding is not an encryption method and is considered the same as plain text.</strong></li>
<li>Applications still need to protect the value of secret after reading it from the volume, such as not accidentally logging it or transmitting it to an untrusted party.</li>
<li><strong>A user who can create a Pod that uses a secret can also see the value of that secret. Even if the API server policy does not allow that user to read the Secret, the user could run a Pod which exposes the secret.</strong></li>
<li><strong>Currently, anyone with root permission on any node can read any secret from the API server</strong>, by impersonating the kubelet. It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node.</li>
</ul>
<p>Also check great post <a href="https://itnext.io/can-kubernetes-keep-a-secret-it-all-depends-what-tool-youre-using-498e5dee9c25" rel="nofollow noreferrer">Can Kubernetes Keep a Secret? It all depends what tool you’re using</a>, especcially &quot;<strong>What’s wrong with Kubernetes plain Secrets?</strong>&quot; part..</p>
<p>I hope that answered your question, but generally @Harsh Manvar  is right: you should have an access first to that secret.</p>
