<p>I'm currently migrating my docker deployment to k8s manifests and I was wondering about the handling of secretes. Currently my docker container fetches /run/secrets/app_secret_key to get the sensitive information inside the container as env var. but does that have any benefit in comparison to k8s secrets handling as on the other side I can also do something like this in my manifest.yaml:</p>
<pre><code>env:
- name: MYSQL_PASSWORD
  valueFrom:
    secretKeyRef:
      name: mysql-password
      key: password
</code></pre>
<p>which than directly brings the secret as a env-variable inside the container ...
The only difference I was able to notice is that if I fetch /run/secrets/app_secret_key inside the container like so (docker-entrypoint.sh):</p>
<pre><code>export APP_SECRET_KEY=&quot;$(cat /run/secrets/app_secret_key)&quot;
</code></pre>
<p>the env var is not visible when I access the container after deployment, it seems that the env var is only available at the &quot;session&quot; where docker-entrypoint.sh gets initially triggered (at container/pod startup).</p>
<p>So my question now is what does make more sense here: simply go with the env: statement shown above or stay with manual fetching /run/secrets/app_secret_key inside the container ...</p>
<p>Thanks in advance</p>

<p>To be frank both are different implementation of same thing you can choose either one but I will prefer kubernetes approch as mounting secret than container reading at run time simply because of visibility.</p>
<p>Won't matter if you look for one container but when we have 30-40+ microservice running accross 4-5+ environment and have like 100 or even 200 secret. In this case one deployment go wrong we can look at deployments manifest and can figure out entire application. We don't have to search for docker file to understand what happening.</p>
