Understanding sourcing secrets in kubernetes spring boot app

Question

I am following this guide to consume secrets: https://docs.spring.io/spring-cloud-kubernetes/docs/current/reference/html/index.html#secrets-propertysource.

It says roughly.

1. save secrets

2. reference secrets in deployment.yml file

      containers:
    - env:
       - name: DB_USERNAME
         valueFrom:
            secretKeyRef:
              name: db-secret
              key: username
       - name: DB_PASSWORD
         valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
   

3. Then it says "You can select the Secrets to consume in a number of ways:" 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)

My questions:

1. If I make the changes suggested in step 3 what changes/improvements does it make for my container/app/pod?
2. Is there no way to be able to avoid all the mapping in step 1 and put all secrets in an env?
3. 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/

question from:https://stackoverflow.com/questions/65891854/understanding-sourcing-secrets-in-kubernetes-spring-boot-app

Answer 1

You can mount all env variables from secret in the following way:

      containers:
        - name: app
          envFrom:
          - secretRef:
              name: db-secret

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:

When enabled, the Fabric8SecretsPropertySource looks up Kubernetes for Secrets from the following sources:

Reading recursively from secrets mounts

Named after the application (as defined by spring.application.name)

Matching some labels

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 mounted into the pod. It is up to what Kubernetes RBAC permissions are given to pod's serviceaccount.

So it tries to search secrets using Kubernetes API and match them against application name or application labels.