<p>I am following this guide to consume secrets: <a href="https://docs.spring.io/spring-cloud-kubernetes/docs/current/reference/html/index.html#secrets-propertysource" rel="nofollow noreferrer">https://docs.spring.io/spring-cloud-kubernetes/docs/current/reference/html/index.html#secrets-propertysource</a>.</p>
<p>It says roughly.</p>
<ol>
<li><p>save secrets</p>
</li>
<li><p>reference secrets in deployment.yml file</p>
<pre><code>   containers:
 - env:
    - name: DB_USERNAME
      valueFrom:
         secretKeyRef:
           name: db-secret
           key: username
    - name: DB_PASSWORD
      valueFrom:
         secretKeyRef:
           name: db-secret
           key: password
</code></pre>
</li>
<li><p>Then it says &quot;You can select the Secrets to consume in a number of ways:&quot; and gives 3 examples. However without doing any of these steps I can still see the secrets in my env perfectly. Futhermore the operations in step 1 and step 2 operate independently of spring boot(save and move secrets into environment variables)</p>
</li>
</ol>
<p>My questions:</p>
<ol>
<li>If I make the changes suggested in step 3 what changes/improvements does it make for my container/app/pod?</li>
<li>Is there no way to be able to avoid all the mapping in step 1 and put all secrets in an env?</li>
<li>they write -Dspring.cloud.kubernetes.secrets.paths=/etc/secrets to source all secrets, how is it they knew secrets were in a folder called /etc/</li>
</ol>

<p>You can mount all env variables from secret in the following way:</p>
<pre><code>      containers:
        - name: app
          envFrom:
          - secretRef:
              name: db-secret
</code></pre>
<p>As for where Spring gets secrets from - I'm not an expert in Spring but it seems there is already an explanation in the link you provided:</p>
<blockquote>
<p>When enabled, the Fabric8SecretsPropertySource looks up Kubernetes for
Secrets from the following sources:</p>
<p>Reading recursively from secrets mounts</p>
<p>Named after the application (as defined by spring.application.name)</p>
<p>Matching some labels</p>
</blockquote>
<p>So it takes secrets from secrets mount (if you mount them as volumes). It also scans Kubernetes API for secrets (i guess in the same namespaces the app is running in). It can do it by utilizing Kubernetes serviceaccount token which by default is always <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server" rel="nofollow noreferrer">mounted</a> into the pod. It is up to what Kubernetes RBAC permissions are given to pod's serviceaccount.</p>
<p>So it tries to search secrets using Kubernetes API and match them against application name or application labels.</p>
