<p>In <code>deployment.yaml</code> file, we don't add username and password but refer them using secret. This way,the username/password don't get stored in code repositories. In <code>secret.yaml</code>, the username and password are encoded in <code>base64</code> (which can be decoded). From best practice persepective, doesn't <code>secret.yaml</code> also get source-controlled somewhere (thereby also storing the username/password in version control). If so, what is the benefit of using <code>Secret</code> ?</p>

Manu Chadha
<p>There are a few aspects to be considered when keeping k8s secrets secret.</p>
<ol>
<li>Data encryption at rest</li>
</ol>
<p>There's the configuration option <code>--encryption-provider-config</code>, which instructs the api server whether and how to encrypt data in etcd. There's lots more in <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/" rel="nofollow noreferrer">the docs</a>.</p>
<ol start="2">
<li>Authorization</li>
</ol>
<p><a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">Role Based Access Control</a> is one authz possibility for k8s. Using it, access to secrets can be restricted, so not every user or service account can see secrets, already existing in the cluster, think of <code>kubectl get secret others-secret -n some-ns -o yaml</code>. With RBAC you can create roles with specific sets of permissions - allowing or not access to secrets per namespace - and then assign those roles to users, groups or even service accounts, as you see fit.</p>
<ol start="3">
<li>Secrets manifests and VCS</li>
</ol>
<p><strong>3.1 Encryption</strong></p>
<p>There are quite a few tools allowing for encryption of files with sensitive data, which would allow you to commit the file with the secrets to a version control system, if that's what you need. A simpler one would be <a href="https://github.com/mozilla/sops" rel="nofollow noreferrer">mozilla SOPS</a> and one somewhat sophisticated and complex might be Vault for example. Whichever it is, it would definitely be nice if not necessary, to be possible to easily integrate it in any delivery pipeline.</p>
<p><strong>3.2 Don't store secrets manifests</strong>
An alternative approach to the above would be to not store any files with secrets. Create the secret and with regular cluster backups (tools like velero for instance) you should have nothing to worry about.</p>
