-
Notifications
You must be signed in to change notification settings - Fork 33
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
allow to map a vault secret to an environment variable with a different name #41
Comments
@geekflyer I think this can be trivially accomplished by referencing the original environment variable key and re-declaring to the variable of your choice:
|
while the above may work (I haven't tried it) it really makes the whole enterprise unnecessarily verbose (and confusing for anyone eventually having to make changes to the config, and not familiar with Daytona limitation). It would really be great to have the This is what I had originally reported in another issue (#99): Furthermore, it seems that it is not possible to store the secret in an "arbitrarily" named env var, the secret key is always used. This is probably "expected behavior" (if one reads the README 3 or 4 times, while experimenting) but it's somewhat limiting:
while one would wish to have instead a |
Currently when using daytona as entrypoint via --secret-env it injects secrets as environment variables with the same name as the secret in vault.
This forces the user to name vault secrets exactly as the application expects them, which is impractical for applications or services which expect very generic environment variable names like
CLIENT_ID
CLIENT_SECRET
and whose source is not in control of the user.Writing secrets with the same generic name to vault makes it hard for developers to understand what a particular secret actually refers and where it is coming from (i.e. by which IDP a secret is issues).
For example let's say you have an app which expects an
OIDC_SECRET
.In your particular setup this secret may be issued by Auth0, and as such I'd prefer to write this secret as
AUTH0_OIDC_SECRET
to vault which makes it much clearer where this came from.So what I'm proposing is to decouple the vault secret name from the environment name and introduce something like
DAYTONA_SECRET_ENV_<suffix>
to set the environment variable name.For example:
The text was updated successfully, but these errors were encountered: