Vault: Sourcing Environment Variables in K8S Deployment descriptor

Vault
1

Hi team. I am having difficult sourcing my environment variables in my Kubernetes Java Spring Boot application Container. My Pod comes up with the correct Init containers to integrate with Vault. I also observed that my Vault secrets were correctly written to the /vault/secrets/config file.

/vault/secrets/config:

export DB_PASSWORD="XXXXXXXXXXXXXXXX"
export ALIAS_NAME="fdil-app"

However, I am clearing doing something wrong when it comes to sourcing the config file: When I log into the container through Rancher or command-line, and I type env, I do not see my Vault entries.

Here are the configs I am using:

Dockerfile (relevant parts):

ENTRYPOINT ["./entrypoint.sh"]

entrypoint.sh:

#!/usr/bin/env ash

exec java $JAVA_OPTS -Xms512M -Xmx512M -jar app.jar

K8S Deployment (relevant parts):

    spec:
      serviceAccount: vault-auth-fdil
      serviceAccountName: vault-auth-fdil
      containers:
        - name: {{ .Values.app.name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          imagePullPolicy: IfNotPresent
          ports:
            - name: server
              protocol: TCP
              containerPort: {{ .Values.service.port }}
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /management/health
              port: {{ .Values.service.port }}
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /management/health
              port: {{ .Values.service.port }}
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 10
          resources:
            limits:
              cpu: {{ .Values.resources.limits.cpu }}
              memory: {{ .Values.resources.limits.memory }}
            requests:
              cpu: {{ .Values.resources.requests.cpu }}
              memory: {{ .Values.resources.requests.memory }}
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: {{ .Values.app.deployEnv }}
          {{- if .Values.deployment.configMaps }}
          envFrom:
            {{- range .Values.deployment.configMaps }}
            - configMapRef:
                name: {{ . }}
            {{- end }}
          {{- end }}
          command:
            ['sh', '-c']
          args:
            ['source /vault/secrets/config && /home/appluser/entrypoint.sh']

The following comes from https://developer.hashicorp.com/vault/docs/platform/k8s/injector/examples:

          command:
            ['sh', '-c']
          args:
            ['source /vault/secrets/config && /home/appluser/entrypoint.sh']

is only one of the very many configuration I have tried. I have tried others, including: https://discuss.hashicorp.com/t/vault-variables-not-fetched-using-approle-auth-method/42436:

args: [ ‘sh’, ‘-c’, ‘source /vault/secrets/config.env && java -jar app.jar’ ]

However, I have had no luck with sourcing the /vault/secrets/config file before running the Spring Boot application. Consequently, Spring Boot cannot read the environment variables it needs to start the application:

application.yaml (relevant parts):

fdil:
  orcl-datasource:
    ...
    password: ${DB_PASSWORD:}
    ....

Spring Boot Code (relevant parts):

    @Value("${fdil.orcl-datasource.password}")
    private String dbPassword;

The dbPassword is null.

Any help would be much appreciated, as I am not entirely sure what to do at the point. Thanks, team!

2

Hey team. Gently bumping this post: Any feedback would be much appreciated. Thanks!

3

I don’t see anything obviously immediately wrong, but there’s a lot of complexity in your setup - Spring in particular is a technology stack I’ve learned to greatly dislike due to complexity.

For a forum post, the more complexity you can remove, e.g. by demonstrating the lack of environment variables via simpler commands, the wider your potential audience for getting people involved in helping you.

It would also help to show any error messages you are encountering, as they may help people spot what is wrong.