CODEWITHSUNDEEP
spring-bootkubernetesspring-autoconfiguration
Funzo
Funzo

Reputation: 1290

Understanding sourcing secrets in kubernetes spring boot app

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/

Upvotes: 1

Views: 775

Answers (1)

Vasilii Angapov
Vasilii Angapov

Reputation: 9032

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.

Upvotes: 1

Related Questions