Missing secret injection in kubernetes.yml (but present in openshift.yml)

[cescoffier]

Describe the bug

The secrets are not injected in the kuberntes.yml file, but are in the openshift.yml file. Secrets are not openshift specific, so they should be available in both.

Pseudo-reproducer

Imagine the following configuration:

quarkus.openshift.env.secrets=postgresql
quarkus.openshift.env.mapping.database-name.from-secret=postgresql
quarkus.openshift.env.mapping.database-name.with-key=database-name
quarkus.openshift.env.mapping.database-username.from-secret=postgresql
quarkus.openshift.env.mapping.database-username.with-key=database-user
quarkus.openshift.env.mapping.database-password.from-secret=postgresql
quarkus.openshift.env.mapping.database-password.with-key=database-password

You expect the secrets to being injected into the container.

The openshift.yml file contains:

env:
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: DATABASE_NAME
          valueFrom:
            secretKeyRef:
              key: database-name
              name: postgresql
        - name: DATABASE_USERNAME
          valueFrom:
            secretKeyRef:
              key: database-user
              name: postgresql
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              key: database-password
              name: postgresql
        - name: JAVA_APP_JAR
          value: /deployments/quarkus-run.jar

But the kubernetes.yml does not contain any reference to the secrets:

env:
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

Real reproducer

https://github.com/ia3andy/rockaclermont-backup

[quarkus-bot[bot]]

/cc @geoand, @manovotn, @mkouba

[geoand]

cc @iocanel

[Ladicek]

My understanding is that whatever is configured under quarkus.openshift.* is OpenShift-specific and hence doesn't go into kubernetes.yml.

If you configured the secrets under quarkus.kubernetes.*, they would go into kubernetes.yml. (And maybe also into openshift.yml? Not sure about that.)

[geoand]

Ah, good point.

I didn't notice that in the supplied configuration!

[cescoffier]

Oh! Right, I didn't realize that, but then, why is the kubernetes.yml generated if I don't have the kubernetes extension (only the openshift one). Also, secrets are Kube, so should we only allow configuration only from kubernetes.

[cescoffier]

So, I just checked with:

quarkus.kubernetes.env.mapping.database-name.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-name.with-key=database-name
quarkus.kubernetes.env.mapping.database-username.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-username.with-key=database-user
quarkus.kubernetes.env.mapping.database-password.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-password.with-key=database-password

And now... they are in the kubernetes.yml but not in the openshift.yml.

[cescoffier]

Even more funny,

If you have:

quarkus.kubernetes.env.secrets=postgresql
quarkus.kubernetes.env.mapping.database-name.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-name.with-key=database-name
quarkus.kubernetes.env.mapping.database-username.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-username.with-key=database-user
quarkus.kubernetes.env.mapping.database-password.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-password.with-key=database-password

quarkus.openshift.env.mapping.database-name.from-secret=postgresql
quarkus.openshift.env.mapping.database-name.with-key=database-name
quarkus.openshift.env.mapping.database-username.from-secret=postgresql
quarkus.openshift.env.mapping.database-username.with-key=database-user
quarkus.openshift.env.mapping.database-password.from-secret=postgresql
quarkus.openshift.env.mapping.database-password.with-key=database-password

Both got the secrets, however (and that was a mistake), I never configured the secret name for openshift, but it was still getting it.

[Ladicek]

If you have the OpenShift extension, you also automatically have the Kubernetes extension :-)

I vaguely recall some debates about whether quarkus.kubernetes.* should also affect openshift.yml or not, but I'm not sure about the outcomes. I'll defer to @iocanel on that.

[geoand]

Is this still an issue?

[cescoffier]

If you just have (with the kubernetes extension):

quarkus.kubernetes.env.secrets=postgresql
quarkus.kubernetes.env.mapping.database-name.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-name.with-key=database-name
quarkus.kubernetes.env.mapping.database-username.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-username.with-key=database-user
quarkus.kubernetes.env.mapping.database-password.from-secret=postgresql
quarkus.kubernetes.env.mapping.database-password.with-key=database-password

The secret is now correctly injected in the kybernetes.yaml:

        - env:
            - name: KUBERNETES_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  key: database-password
                  name: postgresql
            - name: DATABASE_USERNAME
              valueFrom:
                secretKeyRef:
                  key: database-user
                  name: postgresql
            - name: DATABASE_NAME
              valueFrom:
                secretKeyRef:
                  key: database-name
                  name: postgresql

Works equally well with the openshift extension. So, closing as out of date.

[geoand]

Thanks for checking!