Pod Environment not accurate when using `envFrom` with `prefix`

[Northburns]

Describe the bug I have a deployment with env and envFrom fields, the latter also has prefix specified. When examining the resulting pod in Lens, the Environment heading doesn't include these prefixes. Link to the Kubernetes API on "EnvFromSource v1 core" for reference.

To Reproduce

Deploy the following two resources. My actual image is a Spring service, but I abridged the issue into this:

apiVersion: v1
data:
  DATABASE: default
  HOST: localhost
  PORT: "5432"
kind: ConfigMap
metadata:
  name: rest-api-ds-6ttfh4mbk5
  namespace: foobar
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rest-api
  namespace: foobar
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: rest-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: rest-api
    spec:
      containers:
      - env:
        - name: SPRING_DATASOURCE_URL
          value: jdbc:postgresql://$(DS_HOST):$(DS_PORT)/$(DS_DATABASE)
        - name: SPRING_DATASOURCE_USERNAME
          value: $(DS_SECRET_username)
        - name: SPRING_DATASOURCE_PASSWORD
          value: $(DS_SECRET_password)
        envFrom:
        - configMapRef:
            name: rest-api-ds-6ttfh4mbk5
          prefix: DS_
        image: nginx:stable
        name: restapi

In Lens, open the resulting Pod, and examine the container's Environment header. It shows:

SPRING_DATASOURCE_PASSWORD: $(DS_SECRET_password)
SPRING_DATASOURCE_URL: jdbc:postgresql://$(DS_HOST):$(DS_PORT)/$(DS_DATABASE)
SPRING_DATASOURCE_USERNAME: $(DS_SECRET_username)
DATABASE: default
HOST: localhost
PORT: 5432

Expected behavior The last three should be:

DS_DATABASE: default
DS_HOST: localhost
DS_PORT: 5432

I am not sure if the first three should be like this. I think it might be nice, but I can also understand if not.

SPRING_DATASOURCE_PASSWORD: $(DS_SECRET_password)
SPRING_DATASOURCE_URL: jdbc:postgresql://localhost:5432/default
SPRING_DATASOURCE_USERNAME: $(DS_SECRET_username)

I copied these values from the running container with clicking "Pod Shell" in the Pod pane, and running env|sort.

Screenshots N/A

Environment (please complete the following information):

• Lens Version: 5.4.6
• OS: Windows
• Installation method (e.g. snap or AppImage in Linux): the default Windows installer

Logs: N/A AFAIK

Kubeconfig: N/A AFAIK

Additional context None..

[Nokel81]

If you kubectl exec into the resulting pod manually what do you get as a result of doing env | sort?

[Northburns]

If you kubectl exec into the resulting pod manually what do you get as a result of doing env | sort?

Sorry, I wasn't too clear on that. When I exec into the pod's container and run env | sort, I get what I expect, i.e.:

DS_DATABASE=default
DS_HOST=localhost
DS_PORT=5432
SPRING_DATASOURCE_PASSWORD=$(DS_SECRET_password)
SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/default
SPRING_DATASOURCE_USERNAME=$(DS_SECRET_username)

I don't have the env vars DS_SECRET_username nor DS_SECRET_password defined, so it's expected Kubernetes doesn't expand them (like in the example in the docs shows).

The pod is created correctly by Kubernetes, as far as I can tell. Lens's pod pane doesn't show the prefixes (HOST instead of DS_HOST). Also, I don't have an opinion, but should Lens's pod pane show the original values or expanded values (see SPRING_DATASOURCE_URL). Expanded values might pose a tricky access right issue.

[Nokel81]

So I am a bit confused about where specifically you see this bug. Is it in the Lens Pod details drawer itself (the one that opens from the right when you click on a pod) or is it if you click through to a "Pod Shell"?

[Northburns]

So I am a bit confused about where specifically you see this bug. Is it in the Lens Pod details drawer itself (the one that opens from the right when you click on a pod) or is it if you click through to a "Pod Shell"?

A picture is worth a thousand words 😊

As you can see, the pod's environment env|sort is as expected. It is the Pod details drawer that doesn't add the prefixes.

[Nokel81]

Oh okay, phew I thought you were talking about the pod shell itself. Yes I guess that is a bug.