Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes extension: Support env vars from secrets with a prefix #38604

Closed
wpernath opened this issue Feb 6, 2024 · 10 comments · Fixed by #39782
Closed

Kubernetes extension: Support env vars from secrets with a prefix #38604

wpernath opened this issue Feb 6, 2024 · 10 comments · Fixed by #39782
Labels
Milestone

Comments

@wpernath
Copy link

wpernath commented Feb 6, 2024

Description

Right now you can apply a Secret (or ConfigMap) as environment variables like this:

quarkus.kubernetes.env.secrets=my-secret

This would map all keys of the Secret (or ConfigMap) to the environment of the Kubernetes deployment manifest:

envFrom:
  - secretRef:
       name: my-secret

However, especially when you're dealing with more than - perhaps - one datasource, it would be great to specify also a prefix. Kubernetes supports adding a prefix to imported keys from Secret / ConfigMap.

envFrom:
  - secretRef:
    name: my-secret
  prefix: DB1_

If my-secret contains a key called user it would be mapped to DB1_user, which you then could use to specify your datasource properties in application.properties:

%prod.quarkus.datasource.username=${DB1_user:wanja}

It would be great if Quarkus could allow the specification of a prefix inapplication.properties for example by using this grammar:

quarkus.kubernetes.env.secrets=my-secret[DB1_],my-other-secret[DB2_]

Or by introducing another sub key of env called prefix:

quarkus.kubernetes.env.prefix.my-secret=DB1_

Implementation ideas

No response

@wpernath wpernath added the kind/enhancement New feature or request label Feb 6, 2024
Copy link

quarkus-bot bot commented Feb 6, 2024

/cc @geoand (kubernetes), @iocanel (kubernetes)

@geoand
Copy link
Contributor

geoand commented Feb 6, 2024

Seems reasonable to me! WDYT @iocanel?

@mcruzdev
Copy link
Contributor

mcruzdev commented Feb 7, 2024

Hi @wpernath, can I get this one or do you want to work on this issue?

@wpernath
Copy link
Author

wpernath commented Feb 8, 2024

@mcruzdev, please, please take it. -- Thank you!

@mcruzdev
Copy link
Contributor

mcruzdev commented Feb 8, 2024

Thank you @wpernath!

@mcruzdev
Copy link
Contributor

Hi @iocanel and @geoand , I am making some research before implement the solution. Looking the io.dekorate.kubernetes.config.EnvBuilder, there is no way to configure a prefix for envFrom property. I can be doing some mistakes, but if not there is a solution for this one?

@iocanel
Copy link
Contributor

iocanel commented Mar 4, 2024

@mcruzdev: It's possible that this needs to be implemented in dekorate first. Would you like to give it a try?

@mcruzdev
Copy link
Contributor

mcruzdev commented Mar 4, 2024

Hi @iocanel surely, I will try!

@mcruzdev
Copy link
Contributor

mcruzdev commented Mar 7, 2024

Hi @iocanel, I created the issue on https://github.com/dekorateio/dekorate repo, I will start to work on this tomorrow, thank you!

@mcruzdev
Copy link
Contributor

Hi @iocanel, @wpernath and @geoand I think that the #39782 is done, can you take a look?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants